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ABSTRACT 


This thesis focuses on applying Business Process Reengineering (BPR) to the 
Marine Corps Information Assurance (lA) Certification and Accreditation (C&A) process 
as it pertains to Technology Services Organization-Kansas City (TSO-KC). More 
specifically, the area of research concentrates on analyzing TSO-KC developed 
Department of Defense Information Assurance Certification and Accreditation Process 
(DIACAP) packages for Manpower, Personnel, and Pay systems as they currently 
operate, and the feasibility of applying BPR to the lA security posture required by these 
systems. The goal of this thesis is to effect a radical change in the lA C&A system 
process, resulting in a significant increase in quality or efficiency, a considerable 
reduction in process duration, and an appreciable diminution of cost. 

This thesis discusses the current “As-Is” state of the lA C&A process model for 
TSO-KC IT systems and applications, and discusses methods of improving this proces. 
Potential desired “To-Be” state models are explored using the Knowledge Value Added 
(KVA) methodology, and the most efficient model is developed and validated by 
applying it to the current lA C&A process flow at the TSO-KC. 

Finally, this thesis recommends aspects of BPR initiatives to apply to the lA C&A 
process at the TSO-KC to realize positive change. Areas of follow on study to augment 
the research in this thesis are also briefly discussed. 
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I. 


INTRODUCTION 


A. HISTORY AND EVOLUTION OF THE lA C&A PROCESS 

I. The Need for Information Assurance Certification and Accreditation 
in Marine Corps Information Systems 

An unsecured computer system connected to the Internet can be compromised in 
less than ten minutes (C. Buckley, Captain, personal communication, March 23, 2009). 
With over 350,000 Department of Defense (DoD) computers connected to the Internet 
through the Navy Marine Corps Intranet (NMCI) ("About NMCI," 2009), a single 
weakness can translate to devastating effects throughout the entire Global Information 
Grid (GIG). While each connected node presents a possible avenue of attack and breach 
point into the GIG, it is impractical to disconnect these nodes. Additionally, it is 
unrealistic to assume that all associated risk with each connected node can be completely 
eliminated. 

The Committee on National Security Systems (CNSS), chaired by the DoD, sets 
national policy, establishes operational procedures, promulgates direction, and provides 
guidance for the security of U.S. Government operated Information Systems (ISs). The 
CNSS defines Information Assurance (lA) as the: 

Measures that protect and defend information and information systems by 
ensuring their availability, integrity, authentication, confidentiality, and 
nonrepudiation. These measures include providing for restoration of 
information systems by incorporating protection, detection, and reaction 
capabilities. (CNSSI, 2006, p. 32) 

Additionally, the CNSS defines Certification as a: 

Comprehensive evaluation of the technical and nontechnical security 
safeguards of an IS to support the accreditation process that establishes the 
extent to which a particular design and implementation meets a set of 
specified security requirements. (CNSSI, 2006, p. 8) 
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The CNSS further defines Accreditation as a: 


Formal declaration by a Designated Accrediting Authority (DAA) that an 
IS is approved to operate at an acceptable level of risk, based on the 
implementation of an approved set of technical, managerial, and 
procedural safeguards. (CNSSI, 2006, p. 2) 

lA Certification and Accreditation (C&A), therefore, encapsulates the concept of 
safeguarding an IS while retaining the ability to operate it. lA C&A is not concerned with 
risk elimination but rather risk minimization. The need for IA C&A in USMC 
Information Technology (IT) systems is based on the need to protect the GIG and 
maintain mission readiness through the identification, measurement, control, and 
mitigation of security risks. lA C&A, however, is not limited to networks or external 
threats. The C&A process is necessary for all IT sites and systems, regardless of node 
connectivity, to internal, external, manmade, and natural threats to ensure the protection 
of data on these systems. 

When Automated Data Processing (ADP) equipment first came into use in the 
DoD, the unique security risks of such systems were not fully understood, appreciated, or 
mitigated. Rather, the DoD viewed computers and computer-related systems simply as 
tools for accomplishing tasks in a more proficient manner. As these systems became 
more prevalent, however, it was clear that these systems were susceptible to their own 
inherent weaknesses and flaws. 

As the DoD’s dependence on these systems grew, so did a need to develop an 
Information Security Policy in the DoD. On 15 August 1983, the National Computer 
Security Center (NCSC) issued the first Common Security Criteria Standard. Called 
CSC-STD-001-83, this document provided a set of basic security requirements and 
evaluation controls for developing and assessing trustworthy commercial software and 
hardware products for use in DoD and Government ADP systems. The criteria defined in 
this publication were the basis for the DoD 5200.28-STD, released on 26 December 
1985. Entitled the "Department of Defense Trusted Computer System Evaluation 
Criteria," and more commonly referred to as the “Orange Book” for its orange cover, this 
document was the first of a series of guidelines published by the NCSC to address 
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specific aspects of security criteria and associated evaluation methodologies, policies, and 
responsibilities promulgated by DoD Directive 5200.28. Collectively, these documents, 
all with different colored covers, were known as the “Rainbow Series” and are the 
foundation for Information Assurance in the DoD today. 

2. DoD Information Technology Security Certification and 
Accreditation Process 

The DoD Information Technology Security Certification and Accreditation 
Process (DITSCAP) was promulgated in DoDI 5200.40. The DITSCAP, introduced on 
30 December 1997, required all DoD Information Systems to achieve Certification and 
Accreditation prior to operation. DoDI 5200.40 was a life-cycle approach to security 
accreditation and presented the first standardized information assurance process for all 
DoD systems. The DITSCAP established a standard DOD-wide process, set of activities, 
general tasks, and a management structure to certify and accredit an Information System 
(IS) that will maintain the lA and security posture of the Defense Information 
Infrastructure (DII) throughout the life cycle of the system (K. Burke, personal 
communication, 22 April 2009). The DITSCAP is an important document because it 
established a foundation for the C&A process today. The DITSCAP had four distinct 
phases. Figure I details these phases. 



Figure 1. The Four DITSCAP Phases (After DoDI 5200.40, p. 17) 
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The deliverable for the first DITSCAP phase is the System Security Authorization 
Agreement (SSAA). The SSAA documents the system mission, security requirements, 
classification, architecture, accreditation boundary, schedule, and resources. It also 
defines the C&A level of effort, identifies C&A roles and responsibilities and describes 
the methods implementing security requirements for the system. Figure 2 details the first 
DITSCAP phase. 



Figure 2. DITSCAP Phase One (After DoDI 5200.40, p. 19) 


The second DITSCAP phase verifies the system’s compliance against the 
requirements in the SSAA. The objective of phase two is the detailed analysis of system 
architecture, software design, and life cycle management to ensure the system is fully 
integrated for certification testing and accreditation. Phase two also verifies network 
connection rule compliance, security requirements validation, and vulnerability 
evaluation. Figure 3 details the second DITSCAP phase. 



Figure 3. DITSCAP Phase Two (After DoDI 5200.40, p. 27) 


Phase three of the DITSCAP seeks to obtain system accreditation and 
authorization to operate. Security Test and Evaluation (ST&E) procedures are performed 
to evaluate system conformance with security requirements, mission, and architecture as 
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defined in the SSAA. A certification report is issued, and the phase ends with an 
accreditation decision from the Designated Approving Authority (DAA). Figure 4 details 
the third DITSCAP phase. 



SSAA 


Certification Evaiuation 
Of Integrated System 




1 Phase 1 Definition I 



No 


Develop ^ 

. ^■"•'TCccreditatioir^ 

Yes .1 

Phase 4 

Recommendation 

^ '-..^rantedj.,-''''^ 

Post Accreditation 


Figure 4. DITSCAP Phase Three (After DoDI 5200.40, p. 32) 

The fourth DITSCAP phase starts after the system is given accreditation. During 
this phase, DITSCAP responsibilities shift to the organization(s) operating the system. 
The objective of this final phase is to preserve a strong C&A posture by maintaining an 
acceptable level of residual risk throughout its life cycle, eventually ending with system 
termination. Figure 5 details the fourth DITSCAP phase 



Figure 5. DITSCAP Phase Four (After DoDI 5200.40, p. 38) 

Although DITSCAP brought responsible organizations together and defined a 
continuous C&A process throughout the system life cycle, it was still based on stove- 
piped, stand alone architectures. It lacked the wholly net-centric approach to lA C&A 
that is required of the interconnected GIG. On 6 July 2006 the Assistant Secretary of 
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Defense (Networks and Information Integration)/DoD Chief Information Officer 
(ASD(NII)/DoD CIO) released the interim DoD C&A process guidance. Signed on 28 
November 2007, DoDI 8510.01—the DoD Information Assurance Certification and 
Accreditation Process (DIACAP) officially retired the DITSCAP. 

B. PURPOSE 

This thesis examines the lA C&A process as it pertains to pay, personnel 
accounting and financial systems and applications developed by the Technology Services 
Organization—Kansas City (TSO-KC), Programs & Resources Department (P&R), 
Headquarters, United States Marine Corps (HQMC) located in Kansas City, Missouri. 

Prior to operation of standalone systems or connection with the DoD Global 
Information Grid (GIG), all TSO-KC created IT systems must be certified and accredited 
and receive an Interim Authority to Test (lATT), Authority To Test (ATT), Interim 
Authority to Operate (lATO), or Authority To Operate (ATO) by the Marine Corps’ 
DAA using the DIACAP process. Rather than examining the system or application at the 
end of its development cycle and pursuing certification, the TSO-KC lA team performs 
the C&A process in parallel with development. 

There are three scenarios in which the DIACAP will be initiated: 1) The C&A 
process is employed with the creation of a new system, or if there is a major modification 
to an existing system; 2) All systems undergo an annual review, which ensures that the 
current accreditation is still relevant and up to date; and 3) Systems require ATO renewal 
every three years. This renewal entails an entire system review and all lA controls are 
examined to ensure compliance. 

C. SCOPE 

As with all IS platforms in the DoD, the importance of C&A in pay, personnel 
accounting, and financial systems has risen dramatically in recent years. With the 
migration of these systems to Information Technology (IT) automated platforms, 
ensuring and enforcing information security has become a major issue. The overall focus 
of the TSO-KC has historically been quality assurance, with less effort placed on timely 
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completion and cost minimization. With this in mind, this thesis will capture and 
document the lA C&A process and analyze it from the perspective of Knowledge Value 
Added (KVA) to the process. 

The KVA methodology standardizes and measures the knowledge used in an 
organization’s business process. Through the analysis of KVA, process owners can 
measure the Return on Knowledge (ROK) and Return on Investment (ROI) of specific 
sub-processes within a particular business process. This thesis captures those 
measurements for the current “As-Is” process model. Using the “As-Is” model as a 
baseline, techniques of Business Process Reengineering (BPR) are applied to the model 
to generate a desired “To-Be” process model with the purpose of reducing both overall 
process time and cost, while maintaining or increasing the quality of the process output. 
Two desired models are created, each attempting to achieve a radical change to the flow 
for the DIACAP at the TSO-KC. While maintaining the TSO-KC’s focus for high quality 
of output, the desired models shorten timelines of the overall DIACAP and in turn reduce 
the total costs associated with each DIACAP package. 

1. Technical Services Organization, Kansas City (TSO-KC) 

The TSO-KC is a unique organization in the Marine Corps. The decision to create 
or modify a system originates outside of the TSO-KC. System changes are submitted to 
the TSO-KC in the form of Software Change Requests (SCRs) from the customer, known 
as the functional or requirements manager. (The functional manager later becomes the 
Program Manager (PM); each IS typically has a uniquely assigned PM.) The request is 
submitted through a Configuration Control Board (CCB), one of the steps in the Software 
Development Life Cycle (SDLC). The CCB is typically co-chaired by both the TSO-KC 
(as the systems technical manager) and the functional manager(s). During the CCB, the 
functional manger provides the requirements and outlines the guidelines and standards 
for the proposed system. The TSO-KC responds with project feasibility and estimated 
cost. If the functional manager and TSO-KC agree on the proposed system’s 
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requirements and price, the corresponding TSO-KC division will begin system design. At 
this point, the functional manager becomes the PM for the system. Generally there is no 
lA representative present during any pre-CCB or CCB processes. 

After a TSO-KC division receives approval to begin system development, its 
respective division head assigns an Information Assurance Officer (lAO). The lAO can 
be anyone in the division; the duty is assigned as a collateral billet. Currently, no formal 
training is required for an assigned lAO. Depending on the system architecture 
(mainframe, web-based, tiered, etc.), the lAO is responsible for submitting several 
documents to the TSO-KC Information Assurance Manager (lAM) for verification and 
subsequent forwarding outside the TSO-KC. Collectively, these documents are known as 
the DIACAP Package (formerly known as the SSAA under DITSCAP) and contain the 
System Identification Profile (SIP), the DIACAP Implementation Plan (DIP), the lA 
Controls Plan of Action & Milestones (POA&M), and Supporting Information. Although 
a particular architecture has varying requirements, the following are examples of the 
multitude of supporting information for any C&A effort: 

• System of Records Notice (SORN) 

• Privacy Impact Assessment (PIA) 

• Contingency Plan 

• Contingency Plan Test Date 

• lA Controls Validation 

• Re-Evaluation of lA Controls after POA&M 

• DIACAP Scorecard 

• Accreditation Determination 

• C&A Package Complete 

• Project Manager Review 

• Security Controls Tested 

• Annual Security Review 

• Authority To Operate (ATO; this is the result (approval) of the C&A 
effort) 
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D. METHODOLOGY 


This thesis begins as a case study for the TSO-KC to examine the C&A process as 
it pertains to TSO-KC generated Information Sites and Systems. Although consistently 
evolving, the goal of this thesis is to deliver to the TSO-KC a feasible, practical solution 
to the bottlenecks in their current DIACAP package process flows, thereby decreasing 
cost and time required while maintaining the same level of quality in their produced 
Information Sites and Systems. 

1. Review Available References and Conduct Personal Interviews 

To better understand the DIACAP both as an overall process and specific to the 
TSO-KC, several criteria, standards, directives, instructions, and orders are consulted. 
Additionally, personal interviews are conducted with key participant in the C&A process, 
both at the TSO-KC as well as Headquarters Marine Corps (HQMC) Command, Control, 
Communications, and Computers (C4), in Washington, D.C. 

2. Identify Tools and Model used in the lA C&A Process 

Successful execution of the lA C&A Process is enabled through three inter¬ 
related DoD initiatives: Process, Automation, and Accessible Guidance. The DIACAP 
incorporates two important services, or tools, that allow the policy to remain applicable to 
net-centric C&A: 1) The DIACAP Knowledge Service (KS) and 2) the Enterprise 
Mission Assurance Support Service (eMASS). The DIACAP KS provides an online 
forum, including other users’ expertise, instructions, and templates, to assist in executing 
the DIACAP. The eMASS automates capabilities that enable the DIACAP, helping to 
transition it to a truly electronic medium. Additionally, the Marine Corps procured a 
Commercial-Off-The-Shelf (COTS) product called Xacta to automate the submission and 
status tracking of C&A efforts. TSO-KC was one of the first organizations targeted for 
Xacta implementation, but it is not currently employed at the TSO-KC. 
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3. 


Select Candidate Tools to Achieve a Desired Process Model 


In order to capture the process flow of the DIACAP at the TSO-KC, the Savvion 
Process Modeler software packages is applied to achieve a desired process model of the 
current “As-Is” model, and to develop two desired “To-Be” models of the DIACAP at the 
TSO-KC. These process models are then instantiated to analyze the benefits and 
detriments of the BPR initiatives in order to determine the most advantageous process 
model for the TSO-KC lA C&A process. 

4. Recommend for Further Testing and Potential Implementation any 
Process Model Suitable for Use hy the TSO-KC 

Based on the research gathered and output from the Savvion Process Modeler, the 
TSO-KC has several options to reengineer their lA C&A Process. While these 
recommendations will be explained in detail during the conclusion of this thesis, the 
following bullet points present a brief overview of options available to the TSO-KC: 

• The TSO-KC act as its own Echelon II Major Subordinate Command 
(MSC) throughout the entire C&A life cycle. 

• PMs and User Representatives (URs) be granted Temporary Additional 
Duty (TAD) to TSO-KC from their permanent duty stations during the 
first three DIACAP activities. Additionally, the TSO-KC should maintain 
Operational Control (OPCON) over these key personnel during the 
system’s C&A annual review and reaccreditation. 

• The TSO-KC organically employ a Certifying Authority Representative 
(CAR), a Validator, and four (4) dedicated lAOs. 


10 



II. BACKGROUND 


A. CURRENT ENVIRONMENT 

1. Department of Defense Information Assurance Certification and 
Accreditation Process 

The Department of Defense Information Assurance Certification and 
Accreditation Process (DIACAP) is a net-centric, enterprise approach to Certification and 
Accreditation (C&A) in the DoD. It incorporates a continuous review and monitoring 
process using automated tools, allowing it to be a dynamic policy based on standardized 
Information Assurance (lA) Controls. The dynamic approach incorporated in the 
DIACAP ensures compliance with federal regulations more so than the static approach of 
the DITSCAP because it offers more flexibility and improved response time to changes 
in lA posture. 

The purpose of developing a DIACAP package is to ensure that lA Controls are 
identified, implemented, and validated for all DoD Information Sites and Systems in 
order to determine whether or not these sites or systems are in compliance with the 
Global Information Grid (GIG) and should be granted an Authorization to Operate 
(ATO). The overall goal of the DIACAP is to manage the residual risk of threats and 
vulnerabilities in order to balance the benefits Information Technology (IT) environments 
provide with the risks their use presents. 

The DIACAP differs from the DITSCAP on many levels. The most notable of 
these is the paradigm that no Information System (IS), regardless of mission, platform, or 
software architecture, is a truly stand alone system. lA C&A is no longer effective from 
the perspective of individual information systems. The DIACAP transforms the 
DITSCAP’s “stove pipe” C&A approach and presents a net-centric, enterprise approach 
to C&A. Furthermore, the DIACAP recognizes that DoD Information Sites and Systems 
are fluid, living systems and that lA C&A solutions must be as equally dynamic in nature 
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as the systems they accredit. Several other aspects of these C&A methodologies separate 
the DIACAP from the DITSCAP. Table 1 outlines these major differences between the 
DITSCAP and the DIACAP. 


DITSCAP 

DIACAP 

Platform/system centric 

Net-centric, Enterprise 
approach 

Three year "snapshots" of 
security posture 

Continuous review and 
monitoring 

Paper based 

Automated tools based 

Localized, static security 
requirements 

Dynamic policy based on 
standardized lA controls 

Security Requirements are 
unique to each system 

All systems inherit enterprise¬ 
wide standards and 
requirements 

System operation must be 
reauthorized not less than every 
three years 

lA controls must be 
continuously monitored and 
reviewed not less than annually 

Policy advocates tailoring, but 
process is hard-coded to phases 

Steps are flexible, modular, and 
continuous. Each system works 
to a DIACAP POA&M that 
aligns to the SDLC 

Inaccurate association of ATO 
with perfect and unchanging 
security needs 

ATO means operational risk is 
at an acceptable level to 
support the mission 


Table 1. DITSCAP vs. DIACAP 


The DIACAP is not necessarily more complicated than the DITSCAP, but does 
require a more vigilant and organized attitude toward C&A. Key personnel have very 
specific roles and responsibilities throughout the DIACAP. As such, DIACAP procedures 
are better defined, more precise, and farther detailed than procedures outlined by the 
DITSCAP. Tacit knowledge of well trained, highly educated personnel, gained through 
practical experience in the C&A field, adds considerable value to the process. 
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Additionally, the relationships between various personnel generated by the DIACAP can 
have a synergistically positive or negative effect on every DIACAP package that seeks 
accreditation. 

The DIACAP consists of five separate but intertwined activities. Figure 6 shows 
the DIACAP activities and the cyclic relationship between them. 



Figure 6. The DIACAP Activities (After Buckley, 2009) 

Similar to, but more encompassing than the DITSCAP, the DIACAP is a cycle of 
four activities that continuously evaluate the level of risk inherent in a system and 
establish the best means to reduce that risk. Additionally, the DIACAP contains a fifth 
activity to remove a system from the cycle should it become inactive. The activities that 
make up the DIACAP are I) Initiate and Plan, 2) Implement and Validate lA Controls, 3) 
Make C&A determination and decisions, 4) Maintain accreditation and conduct reviews, 
and 5) Decommission the system. These five activities are detailed as follows: 
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Activity One: Initiate and Plan lA C&A. First, the system that needs C&A must 
be properly identified and registered with the governing DoD Component lA program. 
DIACAP team roles and responsibilities must be assigned, and the Mission Assurance 
Category (MAC) and Confidentiality Level (CL) need to be determined. lA controls are 
identified and assigned based on that MAC and CL determination. The DIACAP 
Implementation Plan (DIP) is developed and initiated to determine how each lA control 
will be met (whether or not inherited, or identifying implementation tasks, responsible 
entities, estimated completion dates, and supporting materials and references). This 
activity is the most important in the DIACAP because subsequent activities are based on 
the C&A plan developed here. If the above is not accurate, the remainder of the activities 
will be flawed. Figure 7 details the first DIACAP activity. 



Figure 7. DIACAP Activity One (From Buckley, 2009) 

Activity Two: Implement and Validate Assigned lA Controls. The DIP is 
executed; lA controls are implemented then validated using validation procedures that 
indentify any preparatory and actual steps, the expected results, and criteria for recording 
the actual results. After the lA controls are validated, actual results are compared to the 
expected results. lA controls that are compliant are recorded in the DIACAP Scorecard. 
For any noncompliant controls, a Plan of Action and Milestone (POA&M) document is 
generated to reassess, re-implement, and revalidate those controls. After an lA control is 
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revalidated and found to be in eomplianee it will be updated to (but not removed from) 
the POA&M. Aetivity two eompletes the C&A paekage and establishes eoneurrence from 
the owning command. Figure 8 details the second DIACAP activity. 





Figure 8. DIACAP Activity Two (From Buckley, 2009) 

Activity Three: Make Certification Determination and Accreditation Decision. In 
this activity, the CA reviews the DIACAP package and makes a certification decision 
based on the contents of the package and the results of the lA controls validation. After 
certification, the DAA issues an accreditation decision based on the mission need, the 
protection of data, the information environment, and the level of acceptable risk inherent 
in the site or system. For units falling under a Major Subordinate Command (MSC) to 
include the TSO-KC, a Certifying Authority Representative (CAR) makes a certification 
determination on whether the system is sufficiently secure, and passes that 
recommendation to the Marine Corps Enterprise Network (MCEN) CA. Test results, lA 
control compliance, and residual risk (the risk remaining after mitigation) are evaluated. 
The MCEN DAA then accepts or does not accept the level of residual risk in the system, 
and issues the accreditation decision. 

In the DIACAP, there are four accreditation decisions. (DoDI 8510.01, 2007, 
p. 19) Each accreditation is also given an Authorization Termination Date (ATD) which 
stipulates the lifespan of that particular accreditation decision. The four accreditation 
decisions are outlined as follows: 
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• Authorization to Operate (ATO). An ATO decision is valid for three years 
from the authorization date, but must be reviewed when a major change to 
the environment or a major modification is made to the system, and at 
least annually. 

• Interim Authorization to Operate (lATO). Based on the ATD, an lATO 
decision is valid for up to, but not more than 180 days. The DAA cannot 
grant more than two consecutive lATOs for a system (360 days 
maximum). 

• Interim Authorization to Test (lATT). An lATT decision may be granted 
in special cases when the system needs authorization to run “live” data or 
in a “live” environment that would be otherwise impractical to achieve. 
An lATT may not be used to avoid validation requirements for an ATO or 
lATO. An lATT is granted with an ATD related specifically to the 
duration of the operational test. 

• Denial of Authorization to Operate (DATO). A DATO decision is issued 
if the DAA deems the corresponding system’s lA design to be inadequate. 
If a system is already running without accreditation, a DATO is issued to 
immediately suspend that system, as DATOs imply an instant ATD. 

The most common accreditation decisions received are ATO or lATO. A DATO 
is rare, as the trust relationships built among the C&A community allow for alternative 
avenues to correct discrepancies and mitigate risk, to an acceptable level prior to reaching 
an accreditation decision. The price for these avenues is often time, resulting in project 
delay. Additionally, incomplete packages are delayed at the CA/DAA level, resulting in 
accreditation delay and significantly contributing to overall project delay. Because the 
third DIACAP activity is performed at the CA and DAA level, the TSO-KC currently has 
no control over its timeliness or even completion. Several personnel interviewed at the 
TSO-KC referred to this activity as the “black hole.” Figure 9 details the third DIACAP 
activity. 
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Certifying Authority Representative (CAR) Makes Certification 
_ _ Determination _ _ 


New Package or 
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System- 


Figure 9. DIACAP Activity Three (From Buckley, 2009) 

Activity Four: Maintain Authorization to Operate and Conduct Reviews. In the 
fourth activity, the system is installed. The site or system is monitored for any security 
related events or changes that may impact its lA posture and require a change in the 
accreditation determination. ATOs are reviewed at least annually and lATOs are 
monitored for upgrade to ATO when lA controls are met and unnecessary risk is 
mitigated (or downgraded to DATO should those risks remain). Situational awareness is 
maintained throughout the lifecycle of the system and reaccreditation of ATO operational 
systems occur every three years. This activity comprises long-term efforts of the system 
owner; it recalls the first three DIACAP activities as required for reaccreditation and 
remains in effect for the life of the site or system. Figure 10 details the fourth DIACAP 
activity. 
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Figure 10. DIACAP Activity Four (From Buckley, 2009) 


Activity Five: Decommission. The final activity in the DIACAP provides for a 
structured, controlled, and complete means of retiring a system. The stakeholders and 
system users are notified of the system decommission. Risk to the remaining environment 
is evaluated. Any affected inheritance relationships are assessed for impact, and the 
system is removed. The system’s DIACAP scorecard, POA&M, and any artifacts or 
supporting documentation are removed and disposed of according to their respective 
classification. Figure 11 details the fifth DIACAP activity. 



Figure 11. DIACAP Activity Five (From Buckley, 2009) 


Figure 12 further explains the cyclic nature of the DIACAP, each of its activities, and the 
tasks associated with each activity. 
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Figure 12. Tasks Associated with Each of the DIACAP Activities (From "DIACAP 

Activities," 2009) 

2. DoD, DON, and USMC Process Restrictions 

DoDI 8500.2 establishes an lA level baseline by assigning specific lA controls to 
all DoD ISs depending on the respective MAC of the system and CL of the data stored, 
processed, and protected by that system. These lA controls support the Federal 
Information Security Management Act (FISMA) of 2002 and are mandatory for all DoD 
organizations. All C&A efforts seek to correctly identify and implement the lA controls 
for a particular system; the DoD C&A process must comply with these controls. 
Requirements are nontechnical and technical in nature. Nontechnical requirements 
include physical protection and administrative rules that support and enforce lA security 
policy. Technical requirements specify the automated functions and processes of a 
particular IT system required to enforce lA policy. These requirements are verified 
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during DIACAP activities two and three. Technical requirements are obtained from 
regulations, directives, and instructions and derived further by the mission of the system 
and lA policy. 

The best way to determine lA requirements for a system is to consult the 
DIACAP Knowledge Service (KS). DoDI 8510.01 instructs the Director of the National 
Security Agency to “Develop the lA component of the GIG architecture and publish 
supporting implementation material in the DIACAP KS” (DoDI 8510.01, p. 5). More 
conclusively, though, subparagraph 6.1 states, “DIACAP implementation is supported by 
the DIACAP KS, a Web-based DoD resource that provides the most current 
requirements, guidance, and tools for implementing and executing the DIACAP, 
including lA control implementation procedures” (DoDI 8510.01, p. 9). It’s these lA 
controls that detail what the DIACAP team must do to/for an IS prior to connecting it to 
the GIG. The DIACAP KS provides lA personnel with a single authorized source of up- 
to-date guidance for implementing the DIACAP. 

Risks and vulnerabilities in IT systems can only be mitigated and never 
completely eliminated. Since the goal is to reduce risk as much as possible to an 
acceptable level, much of C&A is subjective in nature. Guidelines are interpreted 
differently by different people with different objectives. The key to successful C&A is 
the buildup of strong relationships and good rapport through communication and trust. 
Personnel must establish trust in order to achieve a successful accreditation decision. 
Restrictions are enforced at every level to facilitate the building of these relationships. 
Table 2 outlines the billet restrictions in the DIACAP. 

These relationships and their associated restrictions play a pivotal role in 
successfully completing a DIACAP package. The desired “To-Be” process models 
discussed in Chapter Three incorporate these relationships into the Business Process 
Reengineering initiative. Table 2 does not list all the actor roles involved in the DIACAP. 
But because the restrictions outlined in Table 2 are the only relationship limitations 
imposed on the DIACAP by Department of Defense Instruction 8510.01, relationships 
involving other roles remain unclear. Other actors involved in the C&A process but 

whose relationship restrictions are not listed in the below table, such as the CAR, can be 
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implemented at the TSO-KC level as long as their service reflects the spirit of the order. 
Captain Charles Buckley, the Enterprise Information Assurance Officer at Headquarters 
Marine Corps (HQMC) Command, Control, Communications, and Computers (C4), in 
Washington, D.C., states that, “Any unit with a CAR assigned can perform these 
[DIACAP] functions” (C. Buckley, Captain, personal communication, 1 June 2009). As 
stated earlier in this chapter, a CAR acts on behalf of the CA and has the authority to 
make a recommendation for accreditation to the MCEN DAA. 


Relationships 

Allowed 

(Y/N) 

PAA may be a DAA 

Yes 

DAA reports to the PM, SM, or Program Executive Officer (PEO) 

No 

DAA and CA for a DoD IS may be the same person 

Yes 

CIO may be a DAA 

Yes 

CA reports to a DAA 

Yes 

CA reports to the PM , SM, or PEO 

No 

PM or SM and CA both report to the DAA 

Yes 

PM or SM and CA for a DoD IS may be the same person 

No 

PM or SM and DAA for a DoD IS may be the same person 

No 

PM or SM and UR for a DoD IS may be the same person 

No 

PM or SM reports to CA 

No 

PM or SM reports to the CIO 

Yes 

PM or SM reports to the DAA 

Yes 

UR reports to the CIO 

Yes 

UR reports to the PM or SM 

No 

UR reports to the SIAO/CA 

Yes 


Table 2. Allowable relationships among DIACAP personnel (Prom DoDI 8510.01, 

p. 15) 
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The overall goal of the DIACAP is to achieve system or site accreditation and 
allow its operation while mitigating residual risk to as low a level as possible. All 
nontechnical and technical requirements for lA controls must be addressed, and nothing 
in the process can be assumed away. 

3. Xacta Software Tool 

On 23 November 2008, Brigadier General Allen (Director of C4 and CIO of the 
Marine Corps) authorized Marine Corps Bulletin 5239 mandating that all USMC IT 
assets transition to the DIACAP (MarAdmin 663/08). To aid in the achievement of 
automating the C&A process, the USMC implemented a COTS software solution called 
the Xacta lA Manager, created by the Telos Corporation. MCBUL 5239 stated that all 
NIPRNET C&A packages not yet under review (at the CA/DAA level) must use the 
Xacta lA Manager to create and submit C&A documentation. 

The Xacta lA Manager software automates the C&A submission process by 
selecting, validating, and enforcing the lA controls required for a system based on MAC 
and CL, as defined by DoDI 8500.2. In addition, it creates and maintains C&A 
documentation required in the DIACAP. Xacta lA Manager streamlines the entire 
DIACAP by automatically selecting lA controls appropriate for a particular system, 
presenting the validation processes associated with those lA controls, and evaluating 
those controls per the guidelines in the DIACAP. Xacta lA Manager then assists in 
creating the DIACAP accreditation documentation, including the SIP, DIP, DIACAP 
Scorecard, POA&M, and other C&A documentation required for that particular system’s 
accreditation. 

More than the establishment and documentation of a DIACAP package, the Xacta 
lA Manager enables the integration of cross-department functions that impact security, 
continuous updating of lA postures through threat and vulnerability assessments, and 
automatic dynamic remediation of lA procedures. The key benefits of the Xacta lA 
Manager are asset awareness and hardware/software inventory, security configuration 
scanning, security requirements evaluation, DIACAP documentation, continuous risk and 
compliance reporting (for activity four of the DIACAP), continuous lA posture 
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assessment, process automation, vulnerability assessment, management, trend analysis, 
and remediation, and software patch and upgrade automation. These features would allow 
the TSO-KC to integrate its C&A efforts by incorporating personnel, systems, and data to 
create a seamless, synchronized, and automated C&A environment. Figure 13 shows a 
screenshot of the Xacta lA Manager’s lA control compliance report. 



Figure 13. Xacta lA Manager’s lA Control Compliance Report (From "Compliance 

Assessment," 2009) 

B. CURRENT STATE EVALUATION 

Although there is currently no defined C&A process timeline, recent efforts at the 
TSO-KC have taken up to one year to complete. The actual IT system is developed in 
parallel with the C&A documentation. The lAO typically sends required documents to 
the lAM via email or physical “hard” copy. The lA team uses an Excel spreadsheet to 
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track the lAO’s progress. Once all documents are complete, packages are sent to the 
Project Manager (PM; an external actor working within the TSO-KC). The PM owns the 
system. After reviewed by the PM, the C&A documentation is sent to the Certifying 
Authority (CA). The CA also reviews and validates the C&A documents for the system, 
and then sends it to the Designated Approving Authority (DAA). The DAA is the sole 
authority to grant final approval for the system to be placed into production or “go live” 
for Marine Corps’ use. Although the C&A documentation leaves the control of the TSO- 
KC lAM when it’s passed to the PM, the process does not end. Typically, the C&A 
credentials can be delayed or outright rejected by the PM, CA, or DAA. In addition, the 
TSO-KC lA team usually emails the C&A documents to the PM. The PM and CA often 
assign the task to review the C&A package to contracted support whose knowledge and 
understanding of these systems and applications is usually very limited. Often, pieces of 
the C&A documents are misplaced, and need to be resent. 

One of the most difficult aspects of the C&A process at the TSO-KC is that each 
system involves various actors, each with varying levels of expertise regarding the 
overall C&A process. Per system, the actors involved in this process are as follows: 

• Functional Manager: GS12 or Contractor Equivalent (External) 

• TSO-KC Deputy Director: Major (Internal) 

• TSO Division Head: Captain, Major or GS14 (Internal) 

• TSO Branch Head: GS13 (Internal) 

• Information Assurance Manager (lAM): GSI2 (Internal) 

• Information Assurance Personnel: 3 X GS9-GS12, Contractor (Internal) 

• Information Assurance Officer (lAO): Sgt thru CWO, Contractor, GSII- 
13 (Internal) 

• Program Manager (PM): CWO-4, contractor, or GS-12 (External) 

• Certifying Authority (CA): Contractor, GS 12/higher (External) 

• Designated Approving Authority (DAA) GS15 (External) 
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1 . 


Principle C&A Process Benefits 


The personnel at the TSO-KC are competent and knowledgeable. All players in 
the DIACAP team work well together and have a strong commitment to the organization 
and their duties. The TSO-KC transitioned from the DITSCAP to the DIACAP in January 
2007. The Marine Corps Total Force System (MCTFS), an integrated pay and personnel 
system, was the first IS to transition to the DIACAP for the USMC. Every TSO-KC 
generated system has a current ATO. The tacit knowledge, experience, and working 
relationships of the lA staff are invaluable and represent the principle benefits of the 
C&A process at the TSO-KC. 

2. Principle C&A Process Shortfalls 

Although the personnel at the TSO-KC work diligently and continue to make 
mission, the organization is still processing DIACAP packages manually. Rather than 
automate the process flow through the use of the Xacta lA Manager, versions are tracked 
manually and documentation revisions emailed both internally and externally, creating 
inaccurate situational awareness and workload redundancy. When documentation is 
revised, the latest versions may or may not be merged into the final package. 

Additionally, although the organic C&A process occurs analogously with system 
development, the DIACAP flow is not truly followed, and its full benefits are not fully 
realized. URs have very little input into the DIACAP, and do not appear to give an in- 
depth review after the DIACAP package is complete. PMs, more concerned with the 
functionality of the system, are not involved in the DIACAP at an acceptable level of 
commitment. 

The manual implementation of an automated process and the bottlenecks which 
occur at the coupling of the TSO-KC to the PM, CA, and DAA result in time delays and 
increased cost. These are the principle C&A process shortfalls at the TSO-KC. 
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III. PROCESS MODEL DESCRIPTION AND BUSINESS PROCESS 

REENGINEERING GOALS 


A. INTRODUCTION OF PROCESS MODELS 

To better understand the current environment in which the Technical Services 
Organization, Kansas City (TSO-KC) Certification and Accreditation (C&A) effort 
operates, a current baseline “As-Is” process model was designed using the Savvion 
Process Modeler Software. The current process model was created based on three 
separate criteria: 1) Research conducted to gain an accurate understanding of the DoD 
Information Technology Security Certification and Accreditation Process (DITSCAP) 
and DoD Information Assurance Certification and Accreditation Process (DIACAP) and 
the fundamental differences between the two processes; 2) Personal interviews with key 
actors in the TSO-KC C&A process, to include the Information Assurance Manager 
(lAM) and several Information Assurance Officers (lAOs); and 3) Personal interviews 
with key actors at Headquarters Marine Corps (HQMC) Command, Control, 
Communications, and Computers (C4), in Washington, D.C., to include the Enterprise 
Information Assurance Officer and Information Assurance Analysts. 

In addition, two desired “To-Be” process models are developed incorporating 
different levels of BPR initiatives. The desired process models, while based on the same 
criteria as the current model, also included distinct features not present in the current 
model. These models are run and analyzed to determine their affects on the current 
environment. 

I. Process Methodology 

Both the current and desired process models capture only the first three activities 
of the DIACAP at the TSO-KC. As discussed in Chapter II, the first three activities are I) 
Initiate and Plan lA C&A; 2) Implement and Validate Assigned lA Controls; and 3) 
Certification Determination and Accreditation. The first three activities only are captured 
in the process models because these activities encapsulate all action required by the TSO- 
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KC to achieve and maintain an accreditation decision for their Information Systems (ISs). 
The fourth activity, Maintaining Authorization to Operate and Conduct Reviews, initiates 
action on the first three activities and is therefore not captured in the process models. 
Additionally, the fifth activity. Decommission, is outside the scope of the Business 
Process Reengineering (BPR) initiative of this thesis and as such is also not captured in 
the process models. 

2. Process Model Assumptions and Constraints 

The lA C&A process at the TSO-KC proved difficult to model for two main 
reasons: 1) One iteration requires an extremely lengthy process time (over 180 days per 
process instance); and 2) A high degree of variability exists among the actors in the 
process, both in terms of experience (knowledge) and cost. Additionally, knowledge 
value added does not necessarily correlate with increased cost. 

While the Savvion Process Modeler software accurately captures process work 
flows, time, and costs, appropriate modeling necessitated that some assumptions be 
incorporated into both the current and desired model states. To compensate for the 
inherent complexity in this process and to overcome limitations in the Savvion process 
modeler, each process model was implemented under the following assumptions and 
constraints: 

• Iteration Frequency: New process iterations have a normally distributed 
arrival frequency of 30 consecutive days (240 hours), with a standard 
deviation of one full work week (40 hours). 

• Process Model Time: The TSO-KC operates on eight hour days, five days 
a week (i.e., 40-hour work weeks) year round. 50 work weeks compose a 
single work year. Because the Savvion Process Modeler does not support 
Business time, the above time constraints are converted from the constant 
24-hour day of the modeler. 

• Activity Time: Activity times are estimated actual work time for the 
actor(s) to complete the task. Elapsed time is captured through overall 
activity duration. For example, it may take the CA a full work day (eight 
hours) to complete a task, but due to other priorities, the overall duration 
of the activity may last a full work week (40 hours). To effectively capture 
this aspect of the process, each activity is time constrained by three 
aspects: Duration, Work Time, and Randomization Criteria. 
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• Duration is the expected amount of time required to complete an instance 
of a particular activity. Duration determines the due date for activity 
completion. 

• Work Time is the amount of time actually required to complete an 
activity. Work Time is affected by the Randomization Criteria imposed on 
the activity. 

• Randomization Criteria incorporates variation in Work Time for a 
particular activity. The Randomization Criteria for all activities in both the 
current “As-Is” and desired “To-Be” process models is normally 
distributed. 

Pay and Compensation: Participants of different grade and experience are used 
interchangeably in the process (particularly in the lAO billet of the current “As-Is” 
model). To compensate for and provide continuity throughout all three process models, 
all personnel involved in the TSO-KC lA C&A process are tied to salaries based on the 
United States Office of Personnel Management January 2009 hourly basic rates pay 
chart. Figures are in 2009 dollars and do not reflect inflation regardless of the iteration 
process length. All General Schedule (GS) ratings are based at Step One. Locality pay, 
bonuses, and incentive payments are not factored into the model. Additionally, if an actor 
role is external to the lA C&A process in a given model (the CAA, DAA, or members of 
the MCEN C&A Team), then their salary is removed from the process cost since the 
TSO-KC does not provide funding for these personnel. Table 3 illustrates the associated 
personnel costs for (not all personnel play a role in every model). 


Role 

Pay 

Grade 

Hourly 
Basic Rate 

Annual 

Salary 

Remarks 

PM 

GS-12 

$28.45 

$59,383.00 

Internal to all Models 

lAM 

GS-12 

$28.45 

$59,383.00 

Internal to all Models 

lAO 

GS-11 

$23.74 

$49,544.00 

Collateral Duty (not captured) in “As-Is” Model 

User Rep 

GS-5 

$12.95 

$27,026.00 

Internal only to Desired Models 

Validator 

GS-10 

$21.61 

$45,095.00 

Internal only to Desired Model Version A 

CA Rep 

GS-12 

$28.45 

$59,383.00 

Internal only to Desired Model Version A 

MCEN 

C&A Team 

N/A 

$0.00 

$0.00 

External Actors (cost not captured) 

CA 

N/A 

$0.00 

$0.00 

External Actor (cost not captured) 

DAA 

N/A 

$0.00 

$0.00 

External Actor (cost not captured) 


Table 3. Personnel costs in the Process Models 
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Factors unique to the Current “As-Is” Model: The current “As-Is” model captures 
real-world information on the process as it actually exists (through interviews with actual 
personnel involved in the process). Initial observations of the current process are as 
follows (these observations are considered when determining elapsed times and activity 
durations): 

• Actors use email to send documents; no collaborative workspace exists to 
track receipt or location of documents. 

• Although XACTA has been procured to track the C&A process, it is not 
currently implemented. Because of the lack of a formal progress tracking 
system, revision control issues arise through the use of Excel spreadsheets. 

• The lAM is not part of the CCB. The lAM has to work reactively rather 
than proactively. 

• There is no formal training for lAOs; the I AM only gives the I AO an 
appointment letter. Since it's a collateral billet and the lAM is outside the 
lAOs immediate chain of command, that appointment letter does not 
necessarily have a high priority. Because lAOs vary (in experience and 
pay scale) by division, the process has a high degree of variability. 

B. PROCESS MODELS 

1. TSO-KC Current “As-Is” Process Model 

Although DoDI 8510.01 officially retired the DITSCAP and initiated the 
DIACAP in November 2007, the actual transition has been slow to implement throughout 
the DoD. As of the date of this thesis, the majority of units in both the Navy and the 
Marine Corps are using a DITSCAP-DIACAP hybrid or still using the DITSCAP 
altogether (K. Burke, personal communication, 22 April 2009). The TSO-KC, while 
incorporating the DIACAP terminology in their C&A effort, has implemented it with 
DITSCAP procedures. 

Completing the DIACAP at the TSO-KC is personality driven. As detailed in 
Chapter I, the Information Assurance Manager (lAM) and Information Assurance Officer 
(lAO) complete the majority of the process. The Program Manager (PM) does not engage 
in the lA C&A effort to a very high degree. No User Representative is present. All lAOs 
are implemented as a collateral duty, drawn from one of the TSO-KC’s eight divisions. 
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The TSO-KC currently does not have an Echelon II Major Subordinate Command (MSC) 
to review DIACAP packages prior to submission to HQMC C4. The lAM and lAO work 
directly with the Marine Corps Enterprise Network (MCEN) C&A Team and Marine 
Corps Systems Command (MARCORSYSCOM) to complete the DIACAP activities. 

While not expressed as a specific activity, the process model captures factors 
unique to the current “As-Is” model throughout all three activities in the form of duration, 
work time, and randomization criteria. Although the current “As-Is” Savvion process 
model for the TSO-KC DIACAP is executed as all three activities, Eigures 14-16 break 
down each of them for better understanding of each individual activity. 

Activity One of the current “As-Is” process model initiates with a DIACAP 
requirement for a new system or reaccreditation of an active system. The Program 
Manager (PM) registers the system with the DoD Information Technology Portfolio 
Repository - Department of the Navy (DITPR-DON). The DITPR-DON Registry is one 
of the DoD’s authoritative inventories of IT systems used to support the certification 
process service-wide; registering systems with DITPR-DON is a requirement for all IT 
systems. 

Other than registering the system in DITPR-DON, the PM plays a limited role in 
the C&A effort. Eater in the process, the PM reviews the preliminary System 
Identification Profile (SIP), then reviews and approves the SIP and the DIACAP 
Implementation Plan (DIP), but the current process relies on the Information Assurance 
Manager (lAM) and Information Assurance Officer (lAO) to accomplish the majority of 
the processes involved. The TSO-KC does not currently incorporate a User 
Representative into the process, and all other involved actors are external to the TSO-KC. 
As stated in Chapter II, all subsequent activities are dependent on the successful 
completion of the first activity. If the C&A plan developed in activity one is defective, 
the remainder of the activities will be faulty as well. 
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Figure 14. Current “As-Is” TSO-KC DIACAP Aetivity One 


The current “As-Is” model for the first DIACAP activity involves a total of 52 
activities and 8 decision points. The distribution of these activities and decision points, 
along with respective percentages of the total, are outlined in Table 4. The lAM and lAO 
workloads encompass over half of all activities, and the lAM comprises half of all 
decisions for this section of the “As-Is” process. 



PM 

lAM 

lAO 

External 

Actors 

Total 

Activities 

4 

(7.69%) 

19 

(36.54%) 

10 

(19.23%) 

19 

(36.54%) 

52 

(100.00%) 

Decisions 

1 

(12.50%) 

4 

(50.00%) 

0 

(0.00%) 

3 

(37.50%) 

8 

(100.00%) 


Table 4. Current “As-Is” Activity One activities and decision points 
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Activity Two of the current “As-Is” process model executes the DIP and 
implements an Information Assurance (lA) Control Plan. The PM plays no role in this 
activity other than passing the approved DIP from the Marine Corps Enterprise Network 
(MCEN) Designated Approving Authority (DA A) to the I AM for execution. The lAM 
and the lAO build, implement, test, monitor, and document the lA controls for the IS. 
Validation of these controls, however, is passed to the MCEN C&A Team, an external 
organization to, and therefore outside of the purview of, the TSO-KC. 

After the lAM submits the C&A Plan to MCEN, a Validator is assigned. The lA 
Controls are reviewed, validated, and documented. The Validator identifies 
vulnerabilities and determines discrepancies that the lAO and lAM must correct. If 
unmitigated risks exist, the lAO and lAM determine if the existing plan can be corrected 
and proceed or if the plan must be reworked entirely. 

After the lA controls are validated, actual results are analyzed. Successful lA 
controls are recorded in the DIACAP Scorecard. The Validator assigns severity codes 
and documents risk levels of the C&A package, and submits a report to the lAM. 
Noncompliant controls, if any, are documented in a Plan of Action and Milestone 
(POA&M) document for reassessment and re-implementation by the TSO-KC. The C&A 
package cannot continue past activity two until all unmitigated risks are addressed. After 
the C&A package is compiled and both the I AO and lAM perform a final review, the 
lAM submits the C&A package to the Certifying Authority Representative (also at the 
MCEN) to begin activity three. 

Activity two is time critical because it entails a high degree of interaction between 
the TSO-KC and the MCEN. In the current “As-Is” model, the lAM and lAO 
communicate directly with various external actors at the MCEN. 
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Figure 15. Current “As-Is” TSO-KC DIACAP Activity Two 

The current “As-Is” model for the second DIACAP activity executes a total of 52 
activities and 10 decision points. The distribution of these activities and decision points, 
along with respective percentages of the total, are outlined in Table 5. The lAM and lAO 
perform nearly sixty percent of the activities, and half of all decisions for this section of 
the “As-Is” process. All but one of the activities and all the decisions performed by 
external actors in activity two are accomplished by the MCEN Validator. 



PM 

lAM 

lAO 

External 

Actors 

Total 

Activities 

1 

14 

16 

21 

52 


(1.92%) 

(26.92%) 

(30.77%) 

(40.38%) 

(100.00%) 

Decisions 

0 

2 

3 

5 

10 

(0.00%) 

(20.00%) 

(30.00%) 

(50.00%) 

(100.00%) 


Table 5. Current “As-Is” Activity Two Activities and Decision Points 

Activity Three of the current “As-Is” process model begins when the lAM 

submits the C&A package to the MCEN CAR to initiate the certification determination 

process. The CAR prioritizes the TSO-KC DIACAP package against all other packages 

submitted by Marine Corps units, and reviews it. If errors in the package exist, the lAM, 

lAO, and CAR determine if the package can continue or if it requires corrective action. 
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After the CAR analyzes, documents, and makes a certification determination on 
the C&A package, a MCEN analyst assesses its residual risk and drafts an accreditation 
decision. If the CA concurs with the certification determination and accreditation 
decision, the package moves forward to the MCEN DAA for final approval. The DAA 
issues one of four accreditation decisions based on the mission need and level of 
acceptable residual risk of the site or system. 



Eigure 16. Current “As-Is” TSO-KC DIACAP Activity Three 

The current “As-Is” model for the third DIACAP activity comprises a total of 26 
activities and 7 decision points. The distribution of these activities and decision points, 
along with respective percentages of the total, are outlined in Table 6. The lAM and lAO 
are the only internal actors involved, performing just over ten percent of the activities. All 
other elements (every decision and nearly 90 percent of the activities) for this section of 
the “As-Is” process are performed by external actors. Due to variation in MCEN C&A 
Team personnel, activity three consumes a disproportionate amount of time in the overall 
C&A process. Personnel at the TSO-KC refer to the external portion of this activity as a 
“black hole” in which information is often becomes convoluted, misinterpreted, or lost. 
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PM 

lAM 

lAO 

External 

Actors 

Total 

Activities 

0 

2 

1 

23 

26 



(0.00%) 

(7.69%) 

(3.85%) 

(88.46%) 

(100.00%) 

Decisions 

0 

0 

0 

7 

7 




(0.00%) 

(0.00%) 

(0.00%) 

(100.00%) 

(100.00%) 


Table 6. Current “As-Is” Activity Three Activities and Decision Points 

2. Desired “To-Be” Process Models 

The desired “To-Be” process models, although derived from the current “As-Is” 
model, are generated side by side with the current model. Creating all three models in 
parallel ensures that any aspects of the processes outside of the BPR initiatives remain 
constant for both desired models, allowing the results of each final version to be 
compared with one another in a more objective fashion. 

The desired “To-Be” process models deviate from the current “As-Is” process 
model in several ways, each incorporating different levels of BPR initiatives. The desired 
process models are based on the same criteria as the current model, but also include 
distinct features not present in the current model. These models are run and analyzed to 
determine their affects on the current environment. 

As with the previous process model, the desired “To-Be” Savvion process models 
for the TSO-KC DIACAP are executed as continuous processes, but are also segregated 
into individual activities to facilitate better comprehension of the process flows. Figures 
17 through 22 detail each activity of the versions A and B of the desired “To-Be” process 
model. 

Similar to the current “As-Is” model, the catalyst for the first activity of the 
desired “To-Be” process model version A is an initial accreditation for a new system or 
reaccreditation of an active system. In this model, though, the PM plays a more 
significant role and additional internal actors are introduced. This process model 
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incorporates the use of a User Representative and integrates the Certifying Authority 
Representative and Validator functions as organic to the TSO-KC. The CA and DAA 
remain independent from the TSO-KC to prevent a confliet of interest. 

The PM registers the system with DITPR-DON as well as the DON Application 
and Database Management System (DADMS), which helps to track system 
accountability and compliance. The PM, lAM, and lAO work closely together to create 
the entire C&A plan. The User Rep reviews the SIP and DIP to ensure that proposed lA 
controls do not negate acceptable system performance for the system’s end user. 

In this model, the TSO-KC acts as its own MSC and employs a CAR. After 
concurring with the DIP and SIP, the CAR forwards the lA C&A documents to the 
MCEN. Activity one ends when the DAA returns the approved DIP to the PM. 
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Figure 17. Desired “To-Be” TSO-KC DIACAP Activity One (Ver. A) 

The desired “To-Be” model version A for the first DIACAP activity involves a 
total of 55 activities and 9 decision points. The distribution of these activities and 
decision points, along with respective percentages of the total, are outlined in Table 7. 
The TSO-KC workload for this section of the “To-Be” process comprises approximately 
75 percent of all activities and nearly 80 percent of all decisions, as opposed to less than 
65 percent of the activities and decisions in the “As-Is” version of the process model. 
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PM 

lAM 

lAO 

UR 

Validator 

CAR 

External 

Actors 

Total 

Activities 

6 

18 

9 

3 

0 

5 

14 

55 






(10.91%) 

(32.73%) 

(16.36%) 

(5.45%) 

(0.00%) 

(9.09%) 

(25.45%) 

(100.00%) 

Decisions 

1 

4 

0 

1 

0 

1 

2 

9 





(11.11%) 

(44.44%) 

(0.00%) 

(11.11%) 

(0.00%) 

(11.11%) 

(22.22%) 

(100.00%) 


Table 7. Desired “To-Be” Activity One Activities and Decision Points (Ver. A) 


Activity two of the desired “To-Be” process model version A executes in a 
similar fashion to the current “As-Is” model, but includes the PM and User Rep in more 
activities and decision points. The PM, rather than the lAM, executes the DIP. The lAM 
and I AO implement the lA Control Plan and build the IA controls. 

In this version of the desired “To-Be” process model, validation of the lA controls 
remains internal to the TSO-KC. After the lAM submits the C&A package to the CAR to 
initiate validation, the CAR notifies the MCEN CA and then tasks the TSO-KC 
Validator. 

If the C&A plan needs correction, the Validator passes the package to the lAM 
and lAO for immediate corrective action. If unmitigated risks exist, the PM determines a 
course of action with the lAO and lAM. The PM also contributes to the POA&M to 
correct any noncompliant controls. As with the current “As-Is” model, the lAM and lAO 
perform a final review of the C&A package. In version A of the desired model, however, 
both the User Rep and the PM must review and approve the C&A package prior to 
submission to the CAR to begin activity three. 

Activity two focuses on implementing and validating lA controls, and involves 
the coordination of multiple players to succeed. Version A of the desired “To-Be” model 
concentrates on simplifying the communication among relevant actors in the process by 
keeping the majority of activities organic to the TSO-KC. 
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Figure 18. Desired “To-Be” TSO-KC DIACAP Activity Two (Ver. A) 

The desired “To-Be” model version A for activity two executes a total of 60 
activities and 12 decision points. The distribution of these activities and decision points, 
along with respective percentages of the total, are outlined in Table 8. Version A of the 
desired “To-Be” model for this activity requires eight additional activities and two 
additional decision points over the current model. 

The majority of the additional activities and decision points in version A of the 
desired model are due to the incorporation of a User Rep and the PMs increased 
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involvement in the overall process. Additionally, this version of the desired “To-Be” 
process model transfers nearly every activity (over 98 percent) and every decision (100 
percent) to the purview of the TSO-KC. 



PM 

1AM 

lAO 

UR 

Validator 

CAR 

External 

Actors 

Total 

Activities 

6 

13 

16 

2 

20 

2 

1 

60 




(10.00%) 

(21.67%) 

(26.67%) 

(3.33%) 

(33.33%) 

(3.33%) 

(1.67%) 

(100.00%) 

Decisions 

2 

1 

3 

1 

5 

0 

0 

12 





(16.67%) 

(8.33%) 

(25.00%) 

(8.33%) 

(41.67%) 

(0.00%) 

(0.00%) 

(100.00%) 


Table 8. Desired “To-Be” Activity Two Activities and Decision Points (Ver. A) 

Activity three of the desired “To-Be” process model version A also transfers the 
CAR activities from MCEN to the TSO-KC. The CAR now prioritizes the DIACAP 
package against only other TSO-KC packages, not all packages submitted Marine Corps 
wide. If errors exist in the package, the PM contributes to determining the course of 
action with the lAM, lAO, and CAR. 

After the CAR makes a certification determination, the C&A package passes from 
the TSO-KC to the MCEN where the package is prioritized and assigned an analyst to 
draft an accreditation decision. At this point, the process flow of the desired “To-Be” 
model version A mirrors that of the current “As-Is” process model. The analyst forwards 
the package to the CA, who subsequently forwards it to the MCEN where one of four 
accreditation decisions is assigned. 



Desired “To-Be” TSO-KC DIACAP Activity Three (Ver. A) 
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Eigure 19. 


















The desired “To-Be” model version A for this activity has 29 activities (three 
more than the current “As-Is” model) and 7 decision points (the same amount as the 
current model). The additional activities are due to the PM’s inclusion in correcting any 
errors and in transferring the package from the TSO-KC to the MCEN; in the current 
model, package transfer was accomplished at the end of activity two. The distribution of 
these activities and decision points, along with respective percentages of the total, are 
outlined in Table 9. The TSO-KC controls over half of the activities and decisions for this 
section of the “To-Be” process model, opposed to slightly over ten percent of the 
activities and no decisions in the current model. 



PM 

lAM 

lAO 

UR 

Validator 

CAR 

External 

Actors 

Total 

Activities 

2 

1 

1 

0 

0 

12 

13 

29 



(6.90%) 

(3.45%) 

(3.45%) 

(0.00%) 

(0.00%) 

(41.38%) 

(44.83%) 

(100.00%) 

Decisions 

0 

0 

0 

0 

0 

4 

3 

7 





(0.00%) 

(0.00%) 

(0.00%) 

(0.00%) 

(0.00%) 

(57.14%) 

(42.86%) 

(100.00%) 


Table 9. Desired “To-Be” Activity Three Activities and Decision Points (Ver. A) 

Version B of the desired “To-Be” process model takes a less radical approach 
than version A in applying Business Process Reengineering (BPR) to the TSO-KC C&A 
process. As with version A, the User Rep is introduced and the PM takes a more 
predominant role in the overall process. Also like version A, this process model alters the 
role of the lAO by removing the eight collateral billets and implementing four primary 
billets. External activities, decisions, and roles outlined in the current “As-Is” process 
remain unchanged in the desired “To-Be” process version B. 

The first activity of the desired “To-Be” process model initiates and plans the lA 
C&A plan. The PM registers the system with DITPR-DON and DADMS. The PM, lAM, 
and lAO create the C&A plan. The User Rep must concur with the SIP and DIP prior to 
the lAM submitting them to the MCEN CAR. After submission, the remainder of activity 
one is completed by actors external to the TSO-KC. 
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At the MCEN, the lA C&A doeumentation passes from the CAR to the CA to the 
DAA. Upon eoneurrenee, the DAA returns the approved DIP to the PM for aetion. 



Figure 20. Desired “To-Be” TSO-KC DIACAP Activity One (Ver. B) 


The desired “To-Be” model version B for the activity one consists of 55 activities 
and 9 decision points. The distribution of these activities and decision points, along with 
respective percentages of the total, are outlined in Table 10. Activity and decision point 
allocation of the “To-Be” version B model in this activity is similar to the “As-Is” version 
of the process model. 
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PM 

lAM 

lAO 

UR 

External 

Actors 

Total 

Activities 

6 

(10.91%) 

18 

(32.73%) 

9 

(16.36%) 

3 

(5.45%) 

19 

(34.55%) 

55 

(100.00%) 

Decisions 

1 

(11.11%) 

4 

(44.44%) 

0 

(0.00%) 

1 

(11.11%) 

3 

(33.33%) 

9 

(100.00%) 


Table 10. Desired “To-Be” Aetivity One Aetivities and Decision Points (Ver. B) 

In activity two, Version B of the desired “To-Be” process model is identical to 
version A in function and execution. The only differences are that in version B, the CAR 
and Validator belong to the MCEN rather than the TSO-KC. 

Validation of the lA controls is external to the TSO-KC. The lAM submits the 
C&A package to the MCEN CAR, the CAR notifies the CA, and validation is executed at 
the MCEN. 

Once validation is complete, members of the TSO-KC compile and review the 
entire C&A package for submission to the MCEN CAR to begin activity three. 



Eigure 21. Desired “To-Be” TSO-KC DIACAP Activity Two (Ver. B) 
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Like version A, version B of the desired “To-Be” model for activity two executes 
a total of 60 activities and 12 decision points. The distribution of these activities and 
decision points, along with respective percentages of the total, are outlined in Table 11. 
Version B requires additional activities and decision points over the current “As-Is” 
model for this activity but percentages of responsibility allocation between the TSO-KC 
and external players is similar to the current model. 



PM 

lAM 

lAO 

UR 

External 

Actors 

Total 

Activities 

6 

(10.00%) 

13 

(21.67%) 

16 

(26.67%) 

2 

(3.33%) 

23 

(38.33%) 

60 

(100.00%) 

Decisions 

2 

(16.67%) 

1 

(8.33%) 

3 

(25.00%) 

1 

(8.33%) 

5 

(41.67%) 

12 

(100.00%) 


Table 11. Desired “To-Be” Activity Two Activities and Decision Points (Ver. B) 

Just as version B of the desired “To-Be” process model closely approximates 
version A in activity two, version B also correlates to the current “As-Is” model in 
activity three. The third activity of version B of the desired “To-Be” process model 
executes almost entirely externally to the TSO-KC. The only TSO-KC functions are 
determining action and initiating corrective measures if the MCEN CAR deems that 
errors in the package exist. 

The remainder of the version B process flow in activity three is identical to the 
current “As-Is” process model. It is complete when the DAA issues one of the four 
DIACAP accreditation decisions described in Chapter II. 


45 




Figure 22. Desired “To-Be” TSO-KC DIACAP Aetivity Three (Ver. B) 

Version B of the desired “To-Be” model for the third DIACAP activity involves a 
total of 29 activities and 7 decision points. The distribution of these activities and 
decision points, along with respective percentages of the total, are outlined in Table 12. 
The TSO-KC plays a minimal role in activity three. All other elements (every decision 
and over 85 percent of the activities) for this section of the version B “To-Be” process are 
performed by external actors. The process flow does not address the variation in MCEN 
C&A Team personnel, so activity three of version B continues to have potential for 
consuming a disproportionate amount of time in the overall C&A process. 



PM 

lAM 

lAO 

UR 

External 

Actors 

Total 

Activities 

2 

(6.90%) 

1 

(3.45%) 

1 

(3.45%) 

0 

(0.00%) 

25 

(86.21%) 

29 

(100.00%) 

Decisions 

0 

(0.00%) 

0 

(0.00%) 

0 

(0.00%) 

0 

(0.00%) 

7 

(100.00%) 

7 

(100.00%) 


Table 12. Desired “To-Be” Activity Three Activities and Decision Points (Ver. B) 

Versions A and B of the desired “To-Be” model both incorporate aspects of BPR 
initiatives, but to varying degrees. Although both desired process models reflect several 
similar alterations from the current model, version A of the desired “To-Be” process 
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model deviates from the current “As-Is” model to a greater extent than version B. Table 
13 compares the current model to the desired models, listing the general differences 
between the current “As-Is” and each version of the desired “To-Be” models. 



"As-Is" 

"To-Be" (Version A) 

"To-Be" (Version B) 

Total # of lAO Actors: 

8 (Collateral Duty) 

4 (Primary Duty) 

4 (Primary Duty) 

Validator Actor: 

No (TSO-KC External) 

Yes (TSO-KC Internal) 

No (TSO-KC External) 

CA Representative Actor: 

No (TSO-KC External) 

Yes (TSO-KC Internal) 

No (TSO-KC External) 

Total# of TSO-KC 

Actors: 

10 

(2 primary; 8 collateral) 

9 

(all primary) 

7 

(all primary) 

Total# of TSO-KC 
Activities: 

67 of 130(51.54%) 

116 of 144(80.56%) 

77 of 144 (53.47%) 

Total# of TSO-KC 
Decisions: 

10 of 25 (40.00%) 

23 of 28 (82.14%) 

13 of 28 (46.43%) 

Additional Annual Cost 
to Implement (Est): 

$0 (Baseline Model) 

$329,680.00 

$225,202.00 


Table 13. General Comparison of the “As-Is” and “To-Be” Process Models 


Both versions of the desired “To-Be” process model require the lAO to be a 
primary duty. The estimated additional annual cost to implement each version is based on 
salaries from the United States Office of Personnel Management January 2009 annual 
salary table. All estimations are based on Step One General Schedule (GS) ratings 
without locality pay, bonuses, or incentive payments. These annual estimates do not 
include funds for the PM or lAM because those costs are captured in the current “As-Is” 
version of the process model and as such are not considered as “additional” costs above 
the current costs already incurred by the TSO-KC. 

Version A of the desired “To-Be” process model requires funding for: 

• 4XIAO(GS-ll)($198,176/year) 

• IX User Rep (GS-5) ($27,026/year) 

• 1 X Validator (GS-10) ($45,095/year) 

• lXCARep(GS-12)($59,383/year) 

Version B of the desired “To-Be” process model requires funding for: 

• 4XIAO(GS-ll)($198,176/year) 

• IX User Rep (GS-5) ($27,026/year) 
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Funding for the MCEN C&A Team, the CA, and the DAA are not provided by 
the TSO-KC and therefore are not ineluded in any of the proeess models. Refer to Table 
3 for the eosts assoeiated with the GS ratings used for all proeess models. 

In addition to reconfiguring billet assignments and restructuring certain process 
activities, both versions of the “To-Be” process rely more heavily on Information 
Technology. The Xacta software tool described in Chapter II is implemented at the TSO- 
KC in both versions of the “To-Be” process models. The addition of automatic C&A 
submission and status tracking software requires additional training for personnel at the 
TSO-KC. This additional training is discussed in Chapter IV. 

C. INTENDED IMPROVEMENTS OF THE BPR INITIATIVE 

As stated in Chapter I, the TSO-KC develops and maintains pay, personnel 
accounting, and financial systems for both active and reserve components of the Marine 
Corps. As part of accomplishing this mission, the TSO-KC must also ensure that the 
DIACAP is successfully applied to all systems within its purview. While the TSO-KC is 
capable of achieving certification and accreditation on its systems, research indicates that 
aspects of Business Process Reengineering (BPR) can improve areas of the lA C&A 
process to decrease process time and reduce process costs. 

Business Process Reengineering (BPR) is defined as “The critical analysis and 
radical redesign of existing business processes to achieve breakthrough improvements in 
performance measures.” (Teng et ah, 1994, p.lO) 

Another reference defines BPR as, “the fundamental rethinking and radical 
redesign of business processes to achieve dramatic improvements in critical, 
contemporary measures of performance, such as cost, quality, service, and speed” 
(Hammer and Champy, 1993). 

The application of BPR is not intended to be a slow, cumulative, or incremental 
process. BPR, by the definitions cited above, is designed to achieve radical, 
transformational improvements on a given process. In applying BPR to the TSO-KC lA 
C&A process, this thesis analyzes the Knowledge Value Added (KVA) to the process. 
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By analyzing the KVA to the TSO-KC lA C&A process, the Return on 
Knowledge (ROK) and Return on Investment (ROI) of specific sub-processes within a 
particular business process are measured and compared between the current “As-Is” 
process and the desired “To-Be” processes. The result of this analysis seeks to 
demonstrate the two intended improvements of the BPR initiative stated earlier: A 
decrease in lA C&A process time and a reduction of DIACAP associated costs at the 
TSO-KC. 

1. Desired End State 

This thesis is developed at the request of the Deputy Director, TSO-KC, Programs 
and Resources Dept, HQMC. Therefore, the desired end state of this thesis is the 
actionable adoption of the recommendations presented in this thesis and the incorporation 
of its BPR initiatives, in whole or in part, into the lA C&A process at the TSO-KC, based 
on observed metrics of this thesis’ process models. 
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IV. PROCESS MODEL EVALUATION AND ANALYSIS OE 

RESULTS 


A. PROCESS MODEL EXECUTION 

Each iteration in the process model execution represents a single DIACAP 
package. In the models, DIACAP packages are initiated approximately every 30 days. 
For the purpose of these models, the catalyst for package initiation and the type of 
accreditation each package eventually receives is irrelevant. 

The process models are each executed through the Savvion Process Modeler for 
100 iterations. As each instance in the lA C&A process requires a long process time, the 
number of iterations in the simulation represents an overall duration length of 
approximately 20 years. While 20 years is not considered realistic for the expected life 
span of an IT-related process, 100 iterations provides an adequate amount of data on 
which to base plausible observations. 

After analyzing the “As-Is” process, this thesis concentrates on three aspects of 
change to re-engineer the lA C&A process: 1) Lean Theory, 2) Six Sigma, and 3) Radical 
BPR. Modifications unique to each model are discussed with the analysis of that model’s 
simulation results. The following transformations are true for both versions of the desired 
“To-Be” process models: 

• Lean Theory is implemented to remove waste. The number of lAOs is 
reduced from eight to four in order to save labor cost. The Xacta lA 
Manager software is implemented to automate the lA C&A process and 
provide DIACAP package version control. 

• Six Sigma is applied to reduce variation. The lAOs work directly for the 
lAM to provide consistent management for the billet. Each lAO also 
undergoes 160 hours of formalized training to create a knowledge 
baseline. The PM billet receives 40 hours of supplemental training to 
provide consistency throughout those duties as well. 
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• Radical BPR of the process as a whole is applied to enable certain 
activities to move more efficiently through the process to save time and 
cost. Although version A of the “To-Be” model adopts a more radical 
approach to billet additions, the User Representative actor is integrated 
into the TSO-KC process in both “To-Be” models. 

1. Process Model Metrics 

A side-by-side comparison of all three process models appears at the end of this 
chapter. The results of each process model simulation are analyzed to determine several 
different metrics. These metrics present quantitative indicators of specific attributes; the 
measure and comparison of these properties determines recommendations and 
conclusions outlined in Chapter V. Several metrics are obtained by analyzing the Savvion 
Process Modeler output directly; these include: 

• Process cost: The thesis captures only those costs incurred by the TSO- 
KC. Process costs for each model are calculated using the assumptions 
listed in table three of Chapter III. 

• Process duration: Process duration represents the time required to 
complete all 100 iterations in the model. Because several iterations can 
occur at various points in the process model simultaneously and several 
tasks are accomplished in parallel, duration time is not equal to the sum of 
(but is much less than) the time it takes all actors to complete their 
respective activities. 

• Personnel utilization: The model captures the utilization and idle 
percentages of each actor or group of actors in the process. In cases where 
an actor from a group of actors accomplishes an activity, the utilization 
percentage spans the number of actors in that group. 

• Wait time: Wait time describes the amount of time that actors wait on 
other personnel to complete a task for an iteration in the process prior to 
being able to accomplish their own task(s) on that iteration. Wait time is 
expressed in hours. For contextual purposes, wait time is also explained in 
total weeks lost to waiting per year. For this explanation, wait time is 
calculated as a function of the number of years a particular model requires 
to perform 100 iterations. The three models each have unique process 
completion times and are therefore not directly comparable when 
discussing wait time in weeks lost per year. 
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• Process congestion: Bottlenecks that create congestion occur throughout 
the process. These bottlenecks result from iterations in the process having 
to wait at a beginning of a task for an actor to complete a prior iteration in 
that same task. The relationship between iterations and process congestion 
is similar to the relationship between actors and wait time. 

As stated in Chapter I, this thesis’ scope is to examine the TSO-KC lA C&A 
process and analyze it based on the Knowledge Value Added (KVA) methodology. The 
critical KVA metrics this thesis focuses on are: 

• Actual Learning Time (ALT): ALT is an estimate of, based on interviews 
with Subject Matter Experts involved in the process, the actual time 
required to learn how to accomplish a task. ALT includes both formal and 
on-the-job training, but is not time spent accomplishing a task (i.e., only 
time spent learning). In the case where more than one actor can perform a 
task, ALT is the average learning time of all actors involved. 

• Nominal Learning Time (NLT): NLT, also an estimate using the same 
parameters as ALT, allocates the total amount of knowledge among the 
tasks or actors in the overall process. This thesis focuses on personnel 
involved in the TSO-KC lA C&A process. Therefore, all activities are 
grouped by actor. NLT allocates a portion of the total knowledge in the lA 
C&A process to each actor or group of actors. 

• Times Fired: Knowledge is leveraged every time an actor performs a task. 
Times Fired is a measure of the number of times an actor performs any 
task (and leverages knowledge) in the process. In this thesis. Times Fired 
is measured per hour. Based on the Savvion Process Modeler output. 
Times Fired per hour is the total tasks an actor performs for all iterations 
divided by the duration of entire process in hours. 

• Number of Actors: Although some billets have multiple personnel (e.g., 
the lAO), each activity in all process models requires only one available 
actor from its respective group, rather than all actors in the group, to 
complete. 

• Percentage of IT: The percentage of IT is a measure of how much an actor 
uses IT to accomplish all assigned tasks in the process. The percentage of 
IT can be described as either a “Minor Additive” or a “Knowledge 
Enhancer.” The percentage of IT is also an estimation based on interviews 
with relevant Subject Matter Experts. 

• Total Feaming Time (TFT): TFT is a function of AFT and percentage of 
IT (computed as: TFT = AFT -i- (AFT*%IT)). TFT is used in calculating 
the Return on Knowledge (ROK) and Return on Investment (ROI). 
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• Total Output: The total amount of knowledge an actor requires for the 
entire process is expressed as the Total Output. As with the other variables 
in this analysis, Total Output is measured per hour. Total Output per Hour 
is the Times Fired per Hour multiplied by the Number of Actors 
multiplied by the TLT. Total Output is the numerator in the ROK ratio and 
denominator in the ROI ratio. 

• Actual Work Time (AWT): AWT is the average amount of time an actor 
requires to accomplish each task in the process. Also based on the output 
from the Savvion Process Modeler, AWT is the sum of an actor’s time 
spent working on activities divided by total number of times that actor 
fires knowledge throughout the process. 

• Actual Activity Time: Actual Activity Time is the utilization of an actor or 
group of actors across all iterations during the entire process. Again, the 
unit of time used in this metric is per hour. For each actor, the Actual 
Activity Time per Hour is the Times Fired per Hour multiplied by the 
Actual Work Time. 

• Total Input: The total amount of time an actor requires for the entire 
process is expressed as the Total Input. In this analysis. Total Input is 
measured per hour. Total Input per Hour is the Times Fired per Hour 
multiplied by the Number of Actors multiplied by the AWT. Total Input is 
the denominator in the ROK ratio and numerator in the ROI ratio. 

• Return on Knowledge (ROK): The ROK returns a percentage that 
quantifies the relative efficiency of each actor (or group of actors) in the 
TSO-KC lA C&A process. ROK is the ratio of Total Output divided by 
the Total Input. This thesis concentrates on the TSO-KC. Where ROK is a 
factor, the conclusions and recommendations outlined in Chapter V are 
based on personnel organic to the TSO-KC only. 

• Return on Investment (ROI): The ROI is a cost to benefit ratio and 
provides a measure of the value of the input into each actor (or group of 
actors) in relation to the output produced by that actor (or group of actors) 
in the TSO-KC lA C&A process. ROI is the ratio of Total Input (benefit) 
divided by the Total Output (cost). This thesis concentrates on the TSO- 
KC. Where ROI is a factor, the conclusions and recommendations outlined 
in Chapter V are based on personnel organic to the TSO-KC only. 
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B. ANALYSIS OF PROCESS MODEL SIMULATION RESULTS 

I. Current “As-Is” Process Model 

Several metrics are derived directly from analysis of the Savvion Process Modeler 
simulation results. The complete output of the Savvion “As-Is” process model is located 
in Appendix A. The “As-Is” model acts as a baseline for the lA C&A process. 

The internal cost to the TSO-KC to process 100 DIACAP packages for 
accreditation in the “As-Is” model is just over $2.73 mi llion. The duration time is 48,845 
process hours, or 24.42 years, resulting in an annual cost of approximately $111,700. 

Utilization of TSO-KC organic personnel in the “As-Is” model extends over a 
wide range. The Information Assurance Manager is occupied 98.5 percent of the time 
during the process. The Information Assurance Officer group, a collateral billet 
composed of eight personnel in the “As-Is” process, is employed for only 13.2 percent of 
the process time. (The total utilization percentage of 105 percent for the lAO spans across 
all eight players.) The Program Manager has a utilization rate of only ten percent 
throughout the “As-Is” model of the lA C&A process. 

The average wait time per iteration in the “As-Is” model is over 194 hours. The 
wait time incurred results in the loss of slightly more than 19 total work weeks per year in 
the “As-Is” process model. Additionally, a total of 56 congestion points, 40 of which are 
internal to the TSO-KC, exist in the “As-Is” model. These internal bottlenecks cause 
congestion during the execution of a total of 206 tasks in the process over the course of 
100 iterations. 

Critical KVA metrics on which to base conclusions of the model are also 
calculated. Table 14 includes the detailed statistics of the “As-Is” process data. All 
activities are grouped by Performer. After analyzing the output from the Savvion Process 
Modeler, critical KVA metrics are calculated and summed for KVA analysis. IT is 
determined to be a minor additive for TSO-KC personnel at 15 percent. Comparing 
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Actual Learning Time to Nominal Learning Time reveals an 83 percent correlation. With 
the “As-Is” lA C&A process, the average Return on Knowledge across all actors is 
13,846 percent, while the Cost to Benefit ratio is 48 percent. 

Although total figures are included for comprehension and accuracy, comparisons 
between models and recommendations in Chapter V are based on TSO-KC personnel 
only. All pertinent TSO-KC data in Table 14 is listed in bold. Because the scope of this 
thesis concentrates just on the TSO-KC, the KVA analysis of these models likewise 
focuses only on TSO-KC organic personnel. The average Return on Knowledge and Cost 
to Benefit ratio across only the TSO-KC organic actors is 1,349 percent and 98 percent, 
respeetively. 


"As-Is" KVA Analysis (100 Iterations) 


Processes 

ALT 

(Hours) 

NLT 

Times 

Fired 

per 

Hour 

% 

IT 

TLT 

(Hours) 

Total 

Output 

per 

Hour 

AWT 

(Hours) 

Total 

Input 

per 

Hour 

ROK 

Cost to 
Benefit 
Ratio 

Certifying 

Authority 

640.0 

20% 

0.015 

45% 

928.0 

13.95 

2.49 

0.04 

37242% 

0.27% 

Designated 

Approval 

Authority 

1440.0 

30% 

0.019 

30% 

1872.0 

35.14 

4.74 

0.09 

39517% 

0.25% 

Information 

Assurance 

Manager 

480.0 

20% 

0.066 

15% 

552.0 

36.58 

14.87 

0.99 

3711% 

2.69% 

Information 
Assurance Officer 

8.0 

15% 

0.046 

15% 

9.2 

3.40 

22.78 

8.42 

40% 

247.66% 

MCEN C&A 
Team 

160.0 

15% 

0.090 

50% 

240.0 

4339.60 

10.56 

191.02 

2272% 

4.40% 

Program 

Manager 

24.0 

0% 

0.011 

15% 

27.6 

0.29 

9.35 

0.10 

295% 

33.86% 

Sum (ROK & ROI 
are averages) 

2752.0 

100% 



3628.8 

4428.97 


200.65 

13846% 

48% 

Correlation 

83% 




83% 


TSO-KC Values: 

1349% 

95% 


Table 14. “As-Is” Process Model KVA Analysis 


2. Desired “To-Be” Process Model (Ver. A) 

In addition to applying the changes discussed at the beginning of this chapter, 
version A of the desired “To-Be” model takes action to dramatically alter the proeess 
flow. As stated earlier. Version A of this model adds the User Representative billet to the 
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TSO-KC. While the DIACAP functions to ensure the tenants of confidentiality, integrity, 
and availability are built into the system, the IS must also function as intended. The User 
Representative ensures that the IT system maintains functionality as lA Controls are 
implemented. 

Version A also transfers two additional billets under the purview of the TSO-KC; 
these being the CA Representative and the Validator. Both of these actors allow the TSO- 
KC to act as its own Echelon II Major Subordinate Command (MSC) and buffer the 
disconnect between the TSO-KC and the MCEN. The nature of these relationships are 
allowable under the guidance described in DoD Instruction 8510.01 and detailed in table 
two of Chapter II (DoDI 8510.01, p. 15). The complete output of the Savvion “To-Be” 
process model version A is located in Appendix B. 

Even though the TSO-KC incurs higher labor costs under version A of the “To- 
Be” model, the internal cost to the TSO-KC to process 100 DIACAP packages for 
accreditation is lower than the “As-Is” model, totaling $2.68 million. The duration time is 
also lower than that of the “As-Is” model. To complete 100 iterations, version A requires 
37,622.5 process hours (18.81 years), resulting in an annual cost of approximately 
$142,600. 

Although it includes more billets, personnel utilization of the same actors in this 
model is consistent with the “As-Is” model. Utilization of the lAM is 92.5 percent (down 
from 98.5 percent in the “As-Is”). The lAO group, now a primary billet of four personnel, 
is active 17.9 percent (up from 13.2 percent) of the process time. The PM shows the 
largest change with a usage of 29.4 percent (from ten percent) throughout version A of 
the “To-Be” lA C&A process model. Other actor utilization rates for this process model 
are 20.3 percent for the CA Representative, 11.3 percent for the User Representative, and 
57.4 percent for the Validator. The deltas in the lAM, lAO and PM percentages are the 
result of a redistribution of workload from the lAM and lAO billets in the “As-Is” model. 
The lAO utilization rate increase is due to the reduction of actors in the group. 
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The average wait time per iteration in this “To-Be” model is just more than 108 
hours, approximately 86 hours less than the “As-Is” model. This wait time translates to 
slightly over 14 work weeks lost per year. Lost time incurred through waiting is 
approximately five weeks less per year than the “As-Is” process model. The congestion 
points in the “To-Be” version A model number 110; the majority (94) are internal to the 
TSO-KC. These internal bottlenecks account for congestion during the execution of 317 
tasks in the version A process over the course of 100 iterations. 

The critical KVA metrics of the detailed statistics of the “To-Be” version A 
process data are outlined in table 15. Factors significant to the TSO-KC and of si The 
data summarized in table 14 is collected across all actors in the lA C&A process. Factors 
significant to the TSO-KC and of important value to this thesis are highlighted in the 
table. It is these aspects of the data from which conclusions will be drawn in Chapter V. 

Due to the inclusion of the Xacta lA Manager, IT is considered a knowledge 
enhancer for the CA Rep (40 percent), lAM (45 percent), lAO (40 percent), and 
Validator (50 percent). IT is a minor additive for the PM and User Rep. 

Actual Learning Time increases due to 160 hours of formalized training for the 
lAO and 40 hours of supplemental training for the PM. The correlation between Actual 
Learning Time and Nominal Learning Time improves from 83 percent in the “As-Is” 
model to 86 percent in version A of the “To-Be” model. The average Return on 
Knowledge and Cost to Benefit ratio across all actors is lower, but the average Return on 
Knowledge of just TSO-KC organic actors jumps from 1,349 percent to 4,348 percent. 
The Cost to Benefit ratio, which now includes the CA Rep and Validator (two external 
actors in the “As-Is” process, lowers from 98 percent to 21 percent. 
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"To-Be" (Version A) KVA Analysis (100 Iterations) 


Processes 

ALT 

(Hours) 

NLT 

Times 

Fired 

per 

Hour 

% 

IT 

TLT 

(Hours) 

Total 

Output 

per 

Hour 

AWT 

(Hours) 

Total 

Input 

per 

Hour 

ROK 

Cost to 
Benefit 
Ratio 

Certifying 

Authority 

640.0 

10% 

0.017 

45% 

928.0 

15.59 

2.77 

0.05 

33466% 

0.30% 

CA 

Representative 

480.0 

10% 

0.041 

40% 

672.0 

27.67 

4.94 

0.20 

13616% 

0.73% 

Designated 

Approval 

Authority 

1440.0 

30% 

0.024 

30% 

1872.0 

45.63 

4.76 

0.12 

39345% 

0.25% 

Information 

Assurance 

Manager 

480.0 

15% 

0.076 

45% 

696.0 

53.02 

12.15 

0.93 

5731% 

1.75% 

Information 

Assurance 

Officer 

160.0 

15% 

0.053 

40% 

224.0 

47.08 

13.61 

2.86 

1646% 

6.07% 

MCEN C&A 
Team 

160.0 

10% 

0.029 

50% 

240.0 

1393.21 

14.66 

85.11 

1637% 

6.11% 

Program 

Manager 

40.0 

5% 

0.028 

15% 

46.0 

1.28 

10.61 

0.29 

434% 

23.06% 

User 

Representative 

8.0 

0% 

0.014 

15% 

9.2 

0.12 

8.35 

0.11 

110% 

90.73% 

Validator 

320.0 

5% 

0.054 

50% 

480.0 

26.14 

10.54 

0.57 

4553% 

2.20% 

Sum (ROK & 
ROI are 
averages) 

3728.0 

100% 



5167.2 

1609.74 


90.24 

11171% 

15% 

Cori'elation 

86% 




85% 


TSO-KC 4348% 

Values: 

21% 


Table 15. “To-Be” Process Model KVA Analysis (Ver. A) 


3. Desired “To-Be” Process Model (Ver. B) 

The BPR approach taken by Version B of the desired model requires less 
modification than version A. This version of the “To-Be” model incorporates the changes 
outlined at the beginning of this chapter, but otherwise leaves the process unaltered. 
Again, these changes are: 

• Reduction of the lAO billet from eight collateral billets to four primary 
billets working directly for the I AM. 

• Addition of the User Rep billet to the TSO-KC. 

• Implementation of the Xacta lA Manager software. 

• Formali z ed lAO training of 160 hours. 

• Supplemental PM training of 40 hours. 
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The introduction of these changes to the “As-Is” model has dramatic affects on 
the process outcome. The complete output of the Savvion desired “To-Be” process model 
version B is located in Appendix C. 

Initial analysis reveals that version B of the desired “To-Be” model is the most 
cost effective and time efficient of all the models. The TSO-KC internal cost to process 
100 DIACAP packages for accreditation under version B of the desired model totals 
$1.97 million (a delta of more than $750,000 from the “As-Is” model and $700,000 from 
version A of the “To-Be” model). To complete 100 iterations, version B requires 
35,092.5 process hours (17.55 years), resulting in an annual cost of roughly $112,700. 
Version B of the desired model completes 100 iterations 13,752.5 hours (almost seven 
years) and 2,530 hours (nearly 1.3 years) faster than the “As-Is” and version A “To-Be” 
models, respectively. 

With version B of the desired process model, the lAM is almost fully exploited at 
98.3 percent, although the lAM billet has strong utilization rates in all three models. The 
lAO group has its highest usage with this model at 19 percent (an increase from 13.2 
percent in the “As-Is” model). The PM and User Rep billets show usage similar to those 
in version A of the “To-Be” model, with corresponding percentages of 31.1 and 11.8. 

Version B of the desired model shows an average wait time per iteration of 
roughly 96 hours; this figure halves the wait time per iteration of the “As-Is” model and 
is a full 12 hours less than version A of the “To-Be” model. The wait time in this model 
equates to more than 13 work weeks lost per year, six weeks less per year than the “As- 
Is” process model. 68 congestion points appear in version B of the “To-Be” model; 53 of 
which are internal to the TSO-KC. These internal bottlenecks account for congestion 
during the execution of 158 tasks in this process model over the course of 100 iterations. 

Table 16 lists the critical KVA metrics of the detailed statistics in the “To-Be” 
version B process model. In this model, IT is considered a knowledge enhancer for the 
lAM (45 percent) and lAO (40 percent). IT is a minor additive for the PM and User Rep 
(15 percent each). 


60 



As with version A of the “To-Be” model, the lAO’s Actual Learning Time is 160 
hours; the PM’s is 40 hours. This model shows the highest correlation of all the process 
models between Actual Learning Time and Nominal Learning Time with 89 percent. 

The average Return on Knowledge and Cost to Benefit ratio for the model as a 
whole is lower than the “As-Is” model. Upon examination of only actors internal to the 
TSO-KC, though, the average Return on Knowledge is 2,013 percent vice the 1,349 
percent of the “As-Is” model. The Cost to Benefit ratio is still lower than the “As-Is” 
model, from 98 percent to 30 percent. 


"To-Be" (Version B) KVA Analysis 
(100 Iterations) 



Processes 

ALT 

(Hours) 

NET 

Times 

Fired 

per 

Hour 

% 

IT 

TLT 

(Hours) 

Total 

Output 

per 

Hour 

AWT 

(Hours) 

Total 

Input 

per 

Hour 

ROK 

Cost to 
Benefit 
Ratio 

Certifying 

Authority 

640.0 

20 % 

0.018 

45% 

928.0 

16.71 

2.71 

0.05 

34288% 

0.29% 

Designated 

Approval 

Authority 

1440.0 

30% 

0.026 

30% 

1872.0 

48.92 

4.65 

0.12 

40216% 

0.25% 

Information 

Assurance 

Manager 

480.0 

15% 

0.082 

45% 

696.0 

57.22 

11.95 

0.98 

5823% 

1.72% 

Information 
Assurance Officer 

160.0 

15% 

0.057 

40% 

224.0 

50.81 

13.40 

3.04 

1672% 

5.98% 

MCEN C&A Team 

160.0 

15% 

0.135 

50% 

240.0 

6460.18 

9.77 

262.86 

2458% 

4.07% 

Program 

Manager 

40.0 

5% 

0.030 

15% 

46.0 

1.38 

10.38 

0.31 

443% 

22.57% 

User 

Representative 

8.0 

0% 

0.014 

15% 

9.2 

0.13 

8.17 

0.12 

113% 

88.76% 

Sum {ROK & ROI 
are averages) 

2928.0 

100% 



4015.2 

6635.35 


267.48 

12145% 

18% 

Correlation 

89% 




90% 


TSO-KC Values: 2013% 

30% 


Table 16. “To-Be” Process Model KVA Analysis (Ver. B) 


C. OBSERVATIONS AND LIMITATIONS OF SIMULATION ANALYSIS 
1. Comparative Analysis of all Process Models 

Based on data produced by the Savvion Process Modeler, each model displays 
both strong and weak attributes. Throughout this chapter, these metrics are listed 
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sequentially for each process model. Comparative analysis of the same metrics across 
100 iterations allows for better comprehension of each model’s individual traits and 
characteristics. 

Table 17 builds on Table 13’s general comparison of the “As-Is” and “To-Be” 
process models in Chapter III by adding the analysis of results examined in this chapter. 
All data is based on 100 iterations. All time units are expressed in hours, and cost figures 
are taken from values listed in the United States Office of Personnel Management 
January 2009 annual salary table. 


Process Models (100 Iterations) 



"As-Is" 

"To-Be" (Version A) 

"To-Be" (Version B) 

Total# of TSO-KC 
Actors: 

10 

(2 primary; 8 collateral) 

9 

(all primary) 

7 

(all primary) 

Total# of TSO-KC 
Activities: 

67 of 130 (51.54%) 

116 of 144(80.56%) 

77 of 144 (53.47%) 

Total# of TSO-KC 
Decisions: 

10 of 25 (40.00%) 

23 of 28 (82.14%) 

13 of 28 (46.43%) 

Additional Annual 

Cost (Estimate): 

$0 (Baseline Model) 

$329,680.00 

$225,202.00 

Average Utility Rate 
per Actor: 

40.57% 

38.14% 

40.04% 

Process Cost 
(2009 dollars): 

$2,729,118.12 

$2,683,126.38 

$1,977,773.03 

Process Duration: 

48,845 hours 

37,622.5 hours 

35,092.5 hours 

Average Process 
Duration per Iteration: 

488.45 hours 

376.23 hours 

350.93 hours 

Average Wait Time 
per Iteration: 

194.37 hours 

108.4 hours 

95.96 hours 

Average Waiting Rate 
per Iteration: 

39.79% 

28.81% 

27.34% 

Congestion Points in 
TSO-KC 

40 

94 

53 

Return on Knowledge 
(TSO-KC) 

1349% 

4348% 

2013% 

Cost to Benefit Ratio 
(TSO-KC) 

95% 

21% 

30% 


Table 17. Comparative Analysis of Model Metrics across 100 Iterations 


2. Limitations of Analysis 

Although two different desired models are created to explore the effects of BPR 
initiatives and compare those to that of the current model, limitations exist. Table 17 
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presents a side by side comparison of several important metrics in the process models, 
revealing strengths and weaknesses of each. Observed individually, each of the analyzed 
metrics is somewhat irrelevant, or perhaps even misleading. 

For example, determining the true cost of the lA C&A process is more convoluted 
than simply recording the analysis of the model results. Metrics involving cost, such as 
process cost per 100 iterations, additional annual implementation cost, years required to 
perform all 100 iterations, and average process time and average waiting time per 
iteration must be weighed and considered accordingly. 

The process model simulations are just that, simulations of the entire process. The 
models must be compared holistically in order to draw accurate inferences and provide 
solid recommendations. The observations inferred from the data output of these models 
are accurate estimations of the effects the TSO-KC may anticipate in the lA C&A process 
should these BPR initiatives be adopted. 

Factors such as dissimilarities between actors, DIACAP packages, and timeline 
criticalities make every instance of the lA C&A process unique. Moreover, the TSO-KC 
is susceptible to external vicissitudes imposed by Headquarters, Marine Corps, future 
DoD policy, and political climate. The Savvion Process Modeler provides mechanisms to 
account for these conditions, but anticipating every nuance in such a complex process is 
impossible. 

The conclusions presented in this thesis are not constrained by the specific BPR 
initiatives introduced in the desired “To-Be” process models. The BPR techniques 
applied to the desired models are not representative of the full range of possibilities 
available to the TSO-KC. Furthermore, minor modifications to either of the desired 
models could have dramatic effects on the outcome of the simulations. Recommendations 
for applying additional BPR techniques to the lA C&A process at the TSO-KC are 
explored in Chapter V. 

After the initial development of the process models, each model originally 
executed through the Savvion Process Modeler for 10 iterations. The simulation length of 
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10 iterations represents duration of approximately 2.5 years in real time. As previously 
indicated and reiterated throughout this chapter, 100 process model iterations of the TSO- 
KC DIACAP equate to roughly 20 years in real time. 

While 2.5 years may be more realistic than 20 years for the expected life span of 
an IT-related process, 10 iterations does not provide enough data on which to base 
plausible observations. 100 iterations of the lA C&A process through the modeling 
software are necessary to achieve a consistent state in the process flow and instill 
confidence in the accuracy of simulation results. Accordingly, the conclusions and 
recommendations in Chapter V of this thesis are extrapolated from process model 
simulations running for 100 iterations. 
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V. CONCLUSIONS AND RECOMMENDATIONS 


A. FEASIBILITY AND SUSTAINABILITY OF EACH MODEL 

As noted in Chapter IV, the eonelusions in this thesis are shaped by, but not 
restrieted to, the BPR initiatives embedded in the desired “To-Be” proeess models. Prior 
to making any credible recommendations concerning the TSO-KC lA C&A process, a 
feasibility and sustainability study determines whether that recommendation is plausible. 

1. Current “As-Is” Model 

By default, the current “As-Is” process model is feasible. The process is currently 
implemented at the TSO-KC and requires no additional action for process execution. This 
thesis, though, determines value in part from Knowledge Value Added to the process. 
From observation and extrapolation of the data in the model simulation, the current 
model contains gaps which prevent it from operating efficiently. 

The Return on Knowledge in the “As-Is” model, as compared to the “To-Be” 
models, demonstrates that it is not sustainable as currently constructed. ROK is poor 
because this model suffers from a lack of formal training among TSO-KC organic actors 
and a failure to capitalize on process automation opportunities. While the personnel 
involved with the lA C&A process continue to produce acceptable results and make 
mission, external factors mandate that the process must change. Implementation of the 
Xacta lA Manager is now directed by Headquarters, Marine Corps (MarAdmin 663/08). 
Even so, as the incorporation of IT enables faster decision making and compresses time, 
continuing to track and communicate lA controls and documentation via spreadsheets 
and email becomes less and less practical. 

2. Desired “To-Be” Model (Ver. A) 

Version A of the desired model is the more radical of the “To-Be” designs, and 
also has the most surprising results. Version A internalizes the majority of activities and 

decision points in the lA C&A process. The anticipation of this model is that while the 
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additional responsibilities incur extra cost, greater quality control and speed are 
appreciated as well. Observation of the data reveals that these results are not the case. 
Version A of the desired model is neither feasible, nor sustainable. 

As this version of the desired model introduces numerous changes to the process, 
it is the most disruptive to the current process flow. Approving funding for the additional 
billets is time consuming and requires budget execution realignment as well as 
restructuring the Table of Organization (T/0) for the entire TSO-KC. The lA C&A 
process is personality driven and the additional billets may alter the political climate at 
the TSO-KC. Attempting to create buy-in or ignoring concerns from current employees at 
the TSO-KC may defeat the purposes of BPR. 

Employing a CA Representative and Validator at the TSO-KC does decrease the 
“Black Hole” effect discussed in Chapters II and III by increasing speed in the process, 
but at a disproportionate increase in internal cost. Simultaneously, this model makes poor 
use of the additional actors. While contributing a large amount of tacit knowledge to the 
process, the CA Representative, a billet normally reserved for an Echelon II Major 
Subordinate Command, is idle nearly 80 percent of the process time. The additional 
billets yields the strongest ROK of all the models, but the TSO-KC does not produce 
enough DIACAP packages to benefit from the inclusion of these actors. As the process 
continues with this scenario, the low Cost to Benefit ratio will be exponentially degrading 
to the effectiveness of the TSO-KC. 

3. Desired “To-Be” Model (Ver. B) 

The ideal outcome of this thesis is to produce a process model that allows the 
TSO-KC to maintain quality assurance while emphasizing timely completion and cost 
minimization. These issues are the primary metrics on which to base final 
recommendations, and a complimentary negotiation between these metrics is the only 
manner in which to assure the goal of this thesis is realized. 

To clarify, the “As-Is” model shows the greatest utility rates for internal TSO-KC 
actors and the highest ROI of all the models tested, but also surrenders the lowest ROK 
and highest process cost and duration. Similarly, the radical version A of the “To-Be” 


66 



model generates the highest ROK at the expense of the lowest utilization rate and ROI of 
all the models. Although originally unintended, version B of the desired model represents 
somewhat of a combination between the other two models. 

Because the model introduces only one additional actor (the User Representative) 
to the process, it’s more feasible than the version A model. Additionally, this desired 
model creates four primary billets for the Information Assurance Officer, freeing the 
TSO-KC Divisions from surrendering personnel for collateral duty. Mitigating the 
budgetary and T/0 adjustment difficulties associated with these additional billets is 
addressed later in this chapter. 

Incorporating the supplementary training outlined in this desired model 
complements the inclusion of the Xacta lA Manager and benefits the lA C&A process 
design. Formal training for the lAOs is a one-time effort that is reinforced during the 
performance of their duties in the process. The supplementary training the Program 
Managers receive does not halt or otherwise adversely affect the actual C&A process. 

While maintaining the same consistent quality in DIACAP package decisions, 
iterations for version B of the desired model require an average of nearly three and a half 
work weeks and $7,500 less to complete over the current model. The “To-Be” version B 
model is the most sustainable through remarkable time and cost reduction, and increased 
Return on Knowledge over the “As-Is” model. 

B. RECOMMENDATION OF BPR INITIATIVES TO THE TSO-KC 

I. Incorporation of the Desired Model into the TSO-KC Process 

After analyzing the simulation metrics, the model that reliably achieves the most 
preferred results of Business Process Reengineering is the less radical version B of the 
desired process model. The conclusion of this thesis proposes the following to the TSO- 
KC for consideration: 

• Include the Information Assurance Manager as a sitting member of all 
Configuration Control Boards (CCBs). Because no Information Assurance 
representative is typically present during any pre-CCB or CCB processes, 
lA personnel often resort to working reactively after decisions are 
completed rather than proactively when decisions are conceived. During 


67 



the CCB, the functional manger provides the requirements and outlines the 
guidelines for the system. Furnished with these approximate details, the 
lAM and lAO can begin generating the System Identification Profile and 
DIACAP Implementation Plan proactively, thus increasing operational 
tempo of the lA C&A process. 

• Adopt the Xacta lA Manager software into the lA C&A process. Not only 
is this solution mandated by Headquarters, Marine Corps, but is also 
largely responsible for the decrease in process duration time. Xacta 
automates lA control selection, implementation, and tracking throughout 
the C&A process. Decision points, designed for redundant quality control 
against human error, have greater success rates and therefore save 
additional time in the process. 

• Incorporate 160 hours of formali z ed training for every lAO and 40 hours 
of supplemental training for every PM. Not only does the additional 
training provide consistency in DIACAP package submission, it also 
shortens activity duration and work time as no impromptu learning is 
required in the execution of specific duties. Moreover, instruction on the 
Xacta lA Manager is easily augmented into this training. 

• Bring the PM into the process full time. All three models integrate the PM 
into the lA C&A process, but the current “As-Is” model does not make 
full use of this inclusion. As stated in Chapter I, the TSO-KC is a unique 
organization in the Marine Corps in that it designs and maintains IT 
systems for other Marine Corps components. While the PM is intimately 
involved in the creation of the actual IT site or system, little effort is given 
to its corresponding lA C&A process. As a result, the lAM and lAO 
perform duties to compensate for the PM. Without the full inclusion of 
this billet, task completion time increases due to less expert input in 
decision making processes. 

• Bring the User Representative into the process. While the PM, lAM, and 
lAO can ensure that a system meets Information Assurance Certification 
and Accreditation requirements, the security of a system is irrelevant if the 
system is unusable. While the User Rep plays a minor role in the overall 
lA C&A process, it’s a critical one, nonetheless. 

• Convert the Information Assurance Officer billet from eight collateral 
duties to four primary duties managed by the Information Assurance 
Manager. Regardless of process model or DIACAP activity, the lAO plays 
an important role in the lA C&A process. The current collateral 
arrangement of pulling individuals from one of the TSO-KC’s eight 
Divisions without any prerequisite qualifications places an unnecessary 
risk on successful DIACAP completion. Structuring the lAO billet under 
the purview of the lAM ensures consistency and priority throughout the 
lA C&A process while allowing the TSO-KC Divisions to concentrate on 
creating the actual IT system. 
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2. 


Modifications to Process Model Recommendations 


Although version B of the desired “To-Be” process model holds the greatest 
potential for successfully implementing aspects of BPR, it is not perfect. From the data 
collected and analyzed during the Savvion Process Modeler simulations, in fact, no one 
complete model can be recommended to the TSO-KC for implementation. Nevertheless, 
the TSO-KC retains several options to reengineer their lA C&A Process. To realize the 
greatest potential for positive results, a modified “To-Be” version B model is 
recommended for the lA C&A process. Modifications to the recommendation include the 
following: 

• Transfer the PM to the TSO-KC under Temporary Additional Duty (TAD) 
orders during the entirety of the first three DIACAP activities. As stated in 
Chapter I, the TSO-KC is unique in that, as an organization, it creates and 
maintains IT sites and systems for other owning components of the Marine 
Corps. Prior to the development of an IS, the PM and TSO-KC agree on a 
proposed system’s price during a Configuration Control Board, and the 
corresponding TSO-KC division begins system design. As the PM must 
remain intimately involved with system design and build, the cost of this 
actor is typically included as TAD costs in the overall development cost 
that the TSO-KC quotes for the system. Because the TSO-KC already 
incorporates the PM’s TAD costs for new systems, this price could also be 
transferred to the owning agency for other scenarios in which the 
DIACAP will be initiated (major modification, annual review, or three 
year recertification). The TSO-KC should maintain Operational Control 
(OPCON) and Administrative Control (ADCON) over the PM during the 
system’s lA C&A initial development, annual review, and reaccreditation. 

• Transfer the User Rep into the TSO-KC under TAD orders from his or her 
parent command at specific points in the lA C&A process. Not directly 
concerned with lA, the User Rep ensures that the security instilled in a 
system does not negate the ability to operate it. The User Rep is idle 
nearly ninety percent of the process time in the version B “To-Be” model, 
but remains a vital component of the process regardless. Bringing the User 
Rep into the process on an as-needed, TAD basis from the system owning 
component saves the TSO-KC from additional annual salary cost, fund 
realignment, and T/0 restructuring. The TSO-KC should maintain 
Operational Control (OPCON) and Administrative Control (ADCON) 
over the User Rep during key points in the system’s lA C&A initial 
development, annual review, and reaccreditation. 
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• Hire a single actor for the Information Assurance Officer primary billet. 
Version B of the “To-Be” process model formats the lAO billet as a 
primary duty involving four actors. Although the number of I AO actors in 
this model halves that of the “As-Is” model, the average utilization rate 
per lAO in the desired version B model is only 19 percent. If only one 
lAO billet exists, the actor would be utilized for 76 percent of the process 
time, remaining idle for 24 percent of the process duration. As observed in 
the model results a single actor, vice four personnel, is adequate for this 
position. 

C. RECOMMENDATIONS FOR FURTHER STUDY 

The applications of BPR initiatives presented in this thesis are based on specific 
input from the TSO-KC Deputy Director (the process owner) to produce a change in 
process flow. To that end, this thesis focuses on aspects of the lA C&A process as it 
applies to the TSO-KC; additional areas of study regarding this specific thesis, the TSO- 
KC, and the lA C&A process are available and relevant. 

Modifications to the process model recommendations discussed in section B of 
this chapter are inferences based on the observed analysis of the process model 
simulations. These modifications have not been simulated in the Savvion Process 
Modeler. Thorough analysis of these modifications may be necessary in order to develop 
enough confidence in them to adopt into the TSO-KC lA C&A process. 

Various facets of adjacent, complimentary, and competing TSO-KC processes are 
not fully examined. For instance, the average wait time in the “As-Is” model is a possibly 
misleading metric, especially for the collateral billet of the lAO, because the process 
model—as well as this thesis—fail to account for other activities that personnel perform 
outside of the lA C&A process. Additional research of the TSO-KC as an organization 
could refine the analytical results produced in this thesis. 

Several obstacles may prevent the BPR initiatives in this thesis from effecting 
positive change in the lA C&A process. This thesis, while focusing on the actual process 
(i.e., the “what”) in order to direct change, does not fully explore the manner (the “how”) 
of implementing these initiatives. Among these are internal influences such as support of 
TSO-KC leadership, concerns of personnel, and natural resistance to change, as well as 
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external factors such as the current Base Realignment and Closure (BRAC) schedule 
which will relocate the Technology Services Organization from Kansas City, Missouri to 
Indianapolis, Indiana in 2011. Follow-on study further analyzing the TSO-KC political 
climate and concentrating on how to implement recommended solutions would augment 
this thesis well. 

The Department of Defense Information Assurance Certification and 
Accreditation Process is a dynamic solution to an evolving problem. The TSO-KC 
represents just one Marine Corps organization involved with this process. Across the 
Marine Corps, DoD services, and other Federal components. Information Assurance is an 
exponentially diverging area of study. To maintain situational awareness and control over 
the increasing threats and vulnerabilities inherent in Information Technology, research in 
this area of study will need to be equally dynamic and evolving. 
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APPENDIX A: “AS-IS” SAVVION PROCESS MODELER OUTPUT 


Simulation Results for TSOKC_DIACAP_AsIs_Final - (100 Packages) 


Duration | 48845:00:00 Time | | Duration hours: | 48845.0 


Process Time And Cost 


Process 

Scenario 

Instance 

T«tal Cost ($) 

Waiting Time 
(Time) 

TotalTune 

(Time) 


TSOKC_DIACAP_AsIs_Final 

(100 Packages) 

100 

2,729,118.12 

2348364:30:00 

2468746:30:00 



Grand 

Total 

2729118.12 

2348364:30:00 

2468746:30:00 

TSOKC_DIACAP_AsIs_Final 

Scenario 

(100 Packages) 

Instances 

100 


Activity 

Performer 

Oeeurs 

Wailing Time 
(Time) 

Tim«4«) 

Complete 

(Time) 

Total Time 
(Time) 

Work 

Time 

(Hours) 

Fired 

per 

Hour 

■»'T 

Analyst Assesses Risk 

Any member of 
MCEN C&A 
Team 

116 

0:00:00 

1873:00:00 

1873:00:00 

1873.0 

0.0619 

16.15 

Analyst Drafts Decision 

Any member of 
MCEN C&A 
Team 

110 

0:00:00 

896:30:00 

896:30:00 

896.5 

0.1227 

8.15 

Analyst Forwards Package 

Any member of 
MCEN C&A 
Team 

no 

0:00:00 

223:00:00 

223:00:00 

223.0 

0.4933 

2.03 

Analyst Reviews Package 

Any member of 
MCEN C&A 
Team 

116 

0:00:00 

967:00:00 

967:00:00 

967.0 

0.1200 

8.34 

CA Acknoledges Receipt of 

SIP 

CA 

100 

6:30:00 

104:00:00 

110:30:00 

104.0 

0.9615 

1.04 

CA Acknowledges Validation 

CA 

102 

7:30:00 

105:30:00 

113:00:00 

105.5 

0.9668 

1.03 

CA Documents Discrepancies 

CA 

6 

0:00:00 

50:30:00 

50:30:00 

50.5 

0.1188 

8.42 

CA Files Preliminary SIP 

CA 

100 

14:30:00 

104:00:00 

118:30:00 

104.0 

0.9615 

1.04 

CA Forwards Package 

CA 

104 

22:30:00 

210:30:00 

233:00:00 

210.5 

0.4941 

2.02 

CA Returns Package to 
Analyst 

CA 

6 

20:00:00 

12:30:00 

32:30:00 

12.5 

0.4800 

2.08 

CA Reviews SIP and DIP 

CA 

no 

25:00:00 

926:00:00 

951:00:00 

926.0 

0.1188 

8.42 

CA Submits DIP to DAA 

CA 

104 

46:30:00 

210:30:00 

257:00:00 

210.5 

0.4941 

2.02 

CA Tasks Validator 

CA 

102 

14:00:00 

105:30:00 

119:30:00 

105.5 

0.9668 

1.03 

CAR Acknoledges Receipt 

Any member of 
MCEN C&A 
Team 

119 

0:00:00 

121:30:00 

121:30:00 

121.5 

0.9794 

1.02 

CAR Acknoledges Receipt of 
SIP 

Any member of 
MCEN C&A 
Team 

100 

0:00:00 

104:00:00 

104:00:00 

104.0 

0.9615 

1.04 

CAR Acknowledges Receipt 

Any member of 
MCEN C&A 
Team 

101 

0:00:00 

105:00:00 

105:00:00 

105.0 

0.9619 

1.04 

CAR Analyzes Package 

Any member of 
MCEN C&A 
Team 

101 

0:00:00 

857:30:00 

857:30:00 

857.5 

0.1178 

8.49 

CAR Analyzes Severity Codes 

Any member of 
MCEN C&A 
Team 

90 

0:00:00 

782:00:00 

782:00:00 

782.0 

0.1151 

8.69 

CAR Determines COA 

Any member of 
MCEN C&A 
Team 

5 

0:00:00 

129:00:00 

129:00:00 

129.0 

0.0388 

25.80 

CAR Determines Certification 

Any member of 
MCEN C&A 
Team 

106 

0:00:00 

1735:00:00 

1735:00:00 

1735.0 

0.0611 

16.37 
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Activity 

Performer 


Wailing Time 
(Time) 

Time to 
Complete 
(Time) 

Total Time 
(Time) 

Work 

Time 

(Hours) 

Fired 

per 

Hour 

AWT 

CAR Documents Corrective 
Action 

Any member of 
MCEN C&A 
Team 

1 

0:00:00 

9:30:00 

9:30:00 

).9.5 

0.1053 

^ 9.50 

CAR Documents Results 

Any member of 
MCEN C&A 
Team 

101 

0:00:00 

614:00:00 

614:00:00 

[ 614.0 

0.1645 

6.08 

CAR Makes Accreditation 

Rec 

Any member of 
MCEN C&A 
Team 

106 

0:00:00 

448:30:00 

448:30:00 

1 448.5 

0.2363 

4.23 

CAR Modifles Severity Codes 

Any member of 
MCEN C&A 
Team 

5 

0:00:00 

64:00:00 

64:00:00 

J 64.0 

0.0781 

12.80 

CAR Notifies CA 

Any member of 
MCEN C&A 
Team 

102 

0:00:00 

105:30:00 

105:30:00 

f 105.5 ■ 

0.9668 

" 1.03 " 

CAR Prioritizes Package 

Any member of 
MCEN C&A 
Team 

101 

0:00:00 

827:00:00 

827:00:00 

1 827.0 

0.1221 

8.19 

CAR Returns Package to 
lAM 

Any member of 
MCEN C&A 
Team 

1 

0:00:00 

2:30:00 

2:30:00 

1 2.5 

0.4000 

2.50 

CAR Reviews Preliminary 

SIP 

Any member of 
MCEN C&A 
Team 

100 

0:00:00 

849:30:00 

849:30:00 

1 849.5 

0.1177 

8.50 

CAR Reviews SIP and DIP 

Any member of 
MCEN C&A 
Team 

119 

0:00:00 

1925:30:00 

1925:30:00 

1 1925.5 

0.0618 

16.18 

CAR Submits SIP and DIP 

Any member of 
MCEN C&A 
Team 

107 

0:00:00 

111:30:00 

111:30:00 

1 111.5 

0.9596 

1.04 

DAA Acknoledges Receipt of 
DIP 

DAA 

104 

78:30:00 

108:00:00 

186:30:00 

[ 108.0 

0.9630 

1.04 

DAA Acknoledges Receipt of 
SIP 

DAA 

100 

0:00:00 

104:00:00 

104:00:00 

[ 104.0 ■ 

0.9615 

" 1.04” 

DAA Files Preliminary SIP 

DAA 

100 

2:30:00 

104:00:00 

106:30:00 

1 104.0 

0.9615 

1.04 

DAA Grants Accreditation 

DAA 

100 

65:30:00 

203:00:00 

268:30:00 

1 203.0 

0.4926 

2.03 

DAA Notifies PM 

DAA 

100 

103:00:00 

203:00:00 

306:00:00 

1 203.0 

0.4926 

2.03 

DAA Returns Approved DIP 
to PM 

DAA 

101 

78:00:00 

205:00:00 

283:00:00 

1 205.0 

0.4927 

2.03 

DAA Returns to Analyst 

DAA 

4 

0:00:00 

9:30:00 

9:30:00 

r9.5- 

0.4211 

2.38 

DAA Reviews CA Comments 

DAA 

104 

18:00:00 

878:00:00 

896:00:00 

■ 878.0 

0.1185 

8.44 

DAA Reviews Package 

DAA 

104 

53:30:00 

1680:00:00 

1733:30:00 

1680.0 

0.0619 

16.15 

DAA Reviews Preliminary 

SIP 

DAA 

100 

9:00:00 

849:30:00 

858:30:00 

849.5 

0.1177 

8.50 

lAM Compiles CA Package 

lAM 

107 

67505:00:00 

2641:00:00 

70146:00:00 

2641.0 

0.0405 

24.68 

lAM Compiles SIP and DIP 

lAM 

119 

91876:30:00 

1914:30:00 

93791:00:00 

1914.5 

0.0622 

16.09 

lAM Confirms System is lAW 
DIP 

lAM 

102 

72353:30:00 

824:00:00 

73177:30:00 

824.0 

0.1238 

8.08 

lAM Corrects DIP 

lAM 

18 

13149:00:00 

438:30:00 

13587:30:00 

438.5 

0.0410 

24.36 

lAM Creates Preliminary 

Plan 

lAM 

133 

101242:00:00 

5393:00:00 

106635:00:00 

5393.0 

0.0247 

40.55 

lAM Creates Preliminary SIP 

lAM 

100 

64680:30:00 

6039:00:00 

70719:30:00 

6039.0 

0.0166 

60.39 

lAM Determines COA 

lAM 

6 

3698:00:00 

204:00:00 

3902:00:00 

204.0 

0.0294 

34.00 

lAM Determines COAl 

lAM 

5 

2981:00:00 

177:30:00 

3158:30:00 

177.5 

0.0282 

35.50 

1AM Determines Inheritance 

lAM 

133 

103144:00:00 

1084:00:00 

104228:00:00 

1084.0 

0.1227 

8.15 

lAM Determines MAC and 

CL 

lAM 

133 

101464:30:00 

270:00:00 

101734:30:00 

270.0 

0.4926 

2.03 

lAM Develops POAM 

lAM 

96 

62136:30:00 

2351:00:00 

64487:30:00 

2351.0 

0.0408 

24.49 

lAM Develops Requirements 

lAM 

133 

99404:00:00 

5393:00:00 

104797:00:00 

5393.0 

0.0247 

40.55 

lAM Executes the DIP 

lAM 

102 

76511:00:00 

835:00:00 

77346:00:00 

835.0 

0.1222 

8.19 
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Activity 

Performer 

0«!«rs 

Waiting Time 
(Time) 

Time to 
Complete 
(Time) 

Total Time 
(Time) 

. Work 
• 1 , Time. 

Fired 

per 

Hour 


lAM Finalizes lA Controls 

1AM 

133 

102472:00:00 

818:00:00 

103290:00:00 

1 818.0 

0.1626 

6.15 

lAM Fixes Problems in Plan 

lAM 

13 

9086:00:00 

156:30:00 

9242:30:00 

156.5 

0.0831 

12.04 

1AM Identifles NonApplicable 

lAM 

133 

103575:00:00 

2167:30:00 

105742:30:00 

2167.5 

0.0614 

16.30 

lAM Identifles the IS 

lAM 

100 

71039:00:00 

203:00:00 

71242:00:00 

203.0 

0.4926 

2.03 

lAM Initiates Corrective 
Action 

lAM 

1 

401:30:00 

9:30:00 

411:00:00 

9.5 

0.1053 

9.50 

lAM Initiates DIP 

lAM 

133 

101928:30:00 

1084:00:00 

103012:30:00 

1 1084.0 

0.1227 

8.15 

1AM Lists Requirements 

lAM 

33 

25876:00:00 

70:00:00 

25946:00:00 

1 70.0 

0.4714 

2.12 

lAM Monitors lA Control 

lAM 

120 

86758:00:00 

4583:30:00 

91341:30:00 

4583.5 

0.0262 

38.20 

lAM Performs Final Review 

lAM 

107 

67264:30:00 

1324:00:00 

68588:30:00 

1324.0 

0.0808 

12.37 

lAM Registers IS with DON 
lA 

lAM 

100 

69411:00:00 

408:00:00 

69819:00:00 

408.0 

0.2451 

4.08 

lAM Reviews Discrepancies 

lAM 

18 

12809:00:00 

150:30:00 

12959:30:00 

1 150.5 

0.1196 

8.36 

lAM Reviews lA Baseline 
Controls 

lAM 

166 

127722:00:00 

2738:00:00 

130460:00:00 

2738.0 

0.0606 

16.49 

lAM Reviews lA Control Plan 

lAM 

102 

76622:30:00 

835:00:00 

77457:30:00 

835.0 

0.1222 

8.19 

1AM Reviews Validation 
Report 

lAM 

101 

67218:30:00 

827:00:00 

68045:30:00 

827.0 

0.1221 

8.19 

lAM Reviews the DIP 

lAM 

148 

114541:00:00 

1195:00:00 

115736:00:00 

1195.0 

0.1238 

8.07 

1AM Submits Package 

lAM 

101 

60990:00:00 

205:00:00 

61195:00:00 

205.0 

0.4927 

2.03 

lAM Submits Packagel 

lAM 

102 

71120:00:00 

207:00:00 

71327:00:00 

207.0 

0.4928 

2.03 

lAM Submits Preliminary 

SIP 

lAM 

100 

68199:00:00 

203:00:00 

68402:00:00 

203.0 

0.4926 

2.03 

lAM Submits SIP and DIP to 
CAR 

lAM 

119 

90503:30:00 

239:30:00 

90743:00:00 

239.5 

0.4969 

2.01 

lAM Tests lA Control 

lAM 

120 

85931:00:00 

2903:30:00 

88834:30:00 

2903.5 

0.0413 

24.20 

lAO Applies Immediate Fixes 

Any member of 
lAO 

12 

0:00:00 

198:00:00 

198:00:00 

198.0 

0.0606 

16.50 

lAO Assembles DIP 
Components 

Any member of 
lAO 

148 

0:00:00 

2444:00:00 

2444:00:00 

2444.0 

0.0606 

16.51 

lAO Assigns Additional 
Controls 

Any member of 
lAO 

33 

0:00:00 

570:00:00 

570:00:00 

570.0 

0.0579 

17.27 

lAO Assigns lA Baseline 
Controls 

Any member of 
lAO 

133 

0:00:00 

4329:00:00 

4329:00:00 

4329.0 

0.0307 

32.55 

lAO Builds lA Controls into 

IS 

Any member of 
lAO 

120 

0:00:00 

2912:00:00 

2912:00:00 

2912.0 

0.0412 

24.27 

lAO Completes POAM 

Any member of 
lAO 

96 

0:00:00 

598:30:00 

598:30:00 

598.5 

0.1604 

6.23 

lAO Corrects DIP 

Any member of 
lAO 

18 

0:00:00 

461:00:00 

461:00:00 

461.0 

0.0390 

25.61 

lAO Creates lA Control List 

Any member of 
lAO 

133 

0:00:00 

2167:30:00 

2167:30:00 

2167.5 

0.0614 

16.30 

lAO Creates Preliminary 

Plan 

Any member of 
lAO 

133 

0:00:00 

5635:30:00 

5635:30:00 

5635.5 

0.0236 

42.37 

lAO Creates Preliminary SIP 

Any member of 
lAO 

100 

0:00:00 

6218:00:00 

6218:00:00 

6218.0 

0.0161 

62.18 

lAO Determines Actions 
Needed 

Any member of 
lAO 

96 

0:00:00 

1183:30:00 

1183:30:00 

1183.5 

0.0811 

12.33 

lAO Determines COA 

Any member of 
lAO 

6 

0:00:00 

204:00:00 

204:00:00 

204.0 

0.0294 

34.00 

lAO Determines COAl 

Any member of 
lAO 

5 

0:00:00 

177:30:00 

177:30:00 

177.5 

0.0282 

35.50 

lAO Determines Fixes 

Any member of 
lAO 

114 

0:00:00 

1871:30:00 

1871:30:00 

1871.5 

0.0609 

16.42 

lAO Develops POAM 

Any member of 
lAO 

96 

0:00:00 

2392:30:00 

2392:30:00 

2392.5 

0.0401 

24.92 

lAO Develops Requirements 

Any member of 
lAO 

133 

0:00:00 

8735:00:00 

8735:00:00 

8735.0 

0.0152 

65.68 
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Activity 

Petsformer 

0«Hirs 

Waiting Time 
(Time) 

Time to 
Cumplete 
(Time) 

Total Time 
(Time) 

, WS£k 

■, Time. 

Fired 

per 

Hour 

, ^^T 

lAO Documents 
Implementation 

Any member of 
lAO 

120 

0:00:00 

1943:30:00 

1943:30:00 

1943,5 

0.0617 

16.20 

lAO Documents Inheritance 

Any member of 
lAO 

133 

0:00:00 

1084:00:00 

1084:00:00 

1084.0 

0.1227 

8.15 

lAO Documents 
NonApplicable 

Any member of 
lAO 

133 

0:00:00 

1635:30:00 

1635:30:00 

1635.5 

0.0813 

12.30 

lAO Fixes Discrepancies 

Any member of 
lAO 

18 

0:00:00 

382:30:00 

382:30:00 

382.5 

0.0471 

21.25 

lAO Fixes Problems in Plan 

Any member of 
lAO 

13 

0:00:00 

159:00:00 

159:00:00 

159.0 

0.0818 

12.23 

lAO Incorporates lA Control 
Plan 

Any member of 
lAO 

120 

0:00:00 

2912:00:00 

2912:00:00 

2912.0 

0.0412 

24.27 

lAO Performs Final Review 

Any member of 
lAO 

107 

0:00:00 

1324:00:00 

1324:00:00 

1324.0 

0.0808 

12.37 

lAO Reviews Documents 

Any member of 
lAO 

102 

0:00:00 

631:00:00 

631:00:00 

631.0 

0.1616 

6.19 

lAO Reviews Validation 
Report 

Any member of 
lAO 

iOl 

0:00:00 

827:00:00 

827:00:00 

827.0 

0.1221 

8.19 

lAO Updates Artifacts 

Any member of 
lAO 

16 

0:00:00 

202:30:00 

202:30:00 

202.5 

0.0790 

12.66 

lAO Updates lA Control Plan 

Any member of 
lAO 

18 

0:00:00 

227:00:00 

227:00:00 

227.0 

0.0793 

12.61 

MCEN Prioritizes Package 

Any member of 
MCEN C&A 
Team 

106 

0:00:00 

867:00:00 

867:00:00 

867.0 

0.1223 

8.18 

PM Acknoledges Receipt of 
SIP 

PM 

100 

13:30:00 

104:00:00 

117:30:00 

104.0 

0.9615 

1.04 

PM Passes DIP to lAM 

PM 

102 

112:30:00 

835:00:00 

947:30:00 

835.0 

0.1222 

8.19 

PM Registers IS in 
DITPRDON 

PM 

100 

88:30:00 

203:00:00 

291:30:00 

203.0 

0.4926 

2.03 

PM Reviews Preliminary SIP 

PM 

100 

116:30:00 

849:30:00 

966:00:00 

849.5 

0.1177 

8.50 

PM Reviews the SIP and DIP 

PM 

119 

54:30:00 

2877:30:00 

2932:00:00 

2877.5 

0.0414 

24.18 

Reviewer Acknoledges 
Receipt 

Any member of 
MCEN C&A 
Team 

107 

0:00:00 

111:30:00 

111:30:00 

111.5 

0.9596 

1.04 

Reviewer Analyzes DIP 

Any member of 
MCEN C&A 
Team 

107 

0:00:00 

4353:00:00 

4353:00:00 

4353.0 

0.0246 

40.68 

Reviewer Documents 
Comments 

Any member of 
MCEN C&A 
Team 

107 

0:00:00 

6493:00:00 

6493:00:00 

6493.0 

0.0165 

60.68 

Reviewer Submits DIP to CA 

Any member of 
MCEN C&A 
Team 

107 

0:00:00 

217:30:00 

217:30:00 

217.5 

0.4920 

2.03 

Site 

lAM 

20 

14424:00:00 

86:30:00 

14510:30:00 

86.5 

0.2312 

4.33 

System 

lAM 

80 

59377:00:00 

167:30:00 

59544:30:00 

167.5 

0.4776 

2.09 

Val Identifies Vulnerabilities 

Any member of 
MCEN C&A 
Team 

114 

0:00:00 

462:00:00 

462:00:00 

462.0 

0.2468 

4.05 

Validator Analyzes Test 
Results 

Any member of 
MCEN C&A 
Team 

114 

0:00:00 

955:00:00 

955:00:00 

955.0 

0.1194 

8.38 

Validator Assesses Risk 

Any member of 
MCEN C&A 
Team 

99 

0:00:00 

1602:30:00 

1602:30:00 

1602.5 

0.0618 

16.19 

Validator Assigns Severity 
Codes 

Any member of 
MCEN C&A 
Team 

99 

0:00:00 

800:00:00 

800:00:00 

800.0 

0.1238 

8.08 

Validator Compiles Test 
Results 

Any member of 
MCEN C&A 
Team 

101 

0:00:00 

827:00:00 

827:00:00 

827.0 

0.1221 

8.19 

Validator Creates Scorecard 

Any member of 
MCEN C&A 
Team 

101 

0:00:00 

412:00:00 

412:00:00 

412.0 

0.2451 

4.08 

Validator Determines Fixes 

Any member of 
MCEN C&A 
Team 

114 

0:00:00 

1840:00:00 

1840:00:00 

1840.0 

0.0620 

16.14 

Validator Determines POAM 

Any member of 
MCEN C&A 
Team 

99 

0:00:00 

399:00:00 

399:00:00 

399.0 

0.2481 

4.03 

Validator Documents Risk 
Levels 

Any member of 
MCEN C&A 
Team 

99 

0:00:00 

602:00:00 

602:00:00 

602.0 

0.1645 

6.08 
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Activity 

Performer 

Occurs 

Waiting Time 
(Time) 

T*in4^44^ 

Complete 

(Time) 

Total Time 
(Time) 

Work 

Time 

(Hours) 

Fired 

per 

Hour 


Validator Documents Test 
Resuits 

Any member of 
MCEN C&A 
Team 

114 

0:00:00 

1384:00:00 

1384:00:00 

1 1384.0' 

0.0824 

■ 12.14' 

Validator Evaluates Impact 

Any member of 
MCEN C&A 
Team 

94 

0:00:00 

773:30:00 

773:30:00 

1 773.5 

0.1215 

8.23 

Validator Maps 
Vulnerabilities 

Any member of 
MCEN C&A 
Team 

113 

0:00:00 

2747:00:00 

2747:00:00 

2747.0 

0.0411 

24.31 

Validator Notes Discrepancies 

Any member of 
MCEN C&A 
Team 

114 

0:00:00 

700:00:00 

700:00:00 

700.0 

0.1629 

6.14 

Validator Notifies PM 

Any member of 
MCEN C&A 
Team 

6 

0:00:00 

12:30:00 

12:30:00 

12.5 

0.4800 

2.08 

Validator Performs GAP 
Analysis 

Any member of 
MCEN C&A 
Team 

114 

0:00:00 

1840:00:00 

1840:00:00 

1840.0 

0.0620 

16.14 

Validator Reviews CA Plan 

Any member of 
MCEN C&A 
Team 

127 

0:00:00 

2051:30:00 

2051:30:00 

2051.5 

0.0619 

16.15 

Validator Reviews Control 
Plan 

Any member of 
MCEN C&A 
Team 

127 

0:00:00 

1063:30:00 

1063:30:00 

1063.5 

0.1194 

8.37 

Validator Reviews Scorecard 

Any member of 
MCEN C&A 
Team 

101 

0:00:00 

412:00:00 

412:00:00 

412.0 

0.2451 

4.08 

Validator Submits Report 

Any member of 
MCEN C&A 
Team 

101 

0:00:00 

205:00:00 

205:00:00 

I 205.0 ■ 

0.4927 

" 2.03 " 

Validator Validates lA 
Controls 

Any member of 
MCEN C&A 
Team 

114 

0:00:00 

2769:30:00 

2769:30:00 

2769.5 

0.0412 

24.29 



ResMirce 

Unit 

C»st/Unit 

Tlire.sliold 

Usage 

CosHS^ 

Times 

Fired 

(Sum) 

Times 

Fired 

per 

Hour 

AWT 
(Hours) 
(Sumi. ^1 

CA 

Hour 

0 

0 

1829:00:00 

0 

i 1 . 734 

0.0150 

2.49183 

DAA 

Hour 

0 

0 

4344:00:00 

0 

917 

0.0188 

4.73719 

lAM 

Hour 

28,45 

0 

48146:00:00 

1369753.7 

3237 

0.0663 

14,8736 

Any member of lAO 

Hour 

23,74 

0 

51425:30:00 

1220841.37 

2257 ■ 

0.0462 

22,7849 

Any member of MCEN C&A 
Team 

Hour 

0 

0 

46651:00:00 

0 

l4416 

0.0904 

10.5641 

PM 

Hour 

28,45 

0 

4869:00:00 

138523.05 

1 521 

0.0107 

9.34549 

Performers queue length and utilization 



Avg 

Min 

Max 

Utilized! %) 

Idle! %) 

CA 

0 

0 

1 

3.74 

96.26 

DAA 

0.01 

0 

2 

8.89 

91.11 

lAM 

48.06 

0 

83 

98.57 

1.43 

Any member of lAO 

0 

0 

0 

13.16 

86.84 

Any member of MCEN C&A 
Team 

0 

0 

0 

0.48 

99.52 

PM 

0.01 

0 

1 

9.97 

90.03 

Bottlenecks 


Process 

Activity 


Avg Queue 
Length 

Min Queue 
Length 

Max Queue 
Length 

TSOKC_DIACAP_AsIs_Final 

CA Acknoledges 
Receipt of SIP 

CA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

CA 

Acknowledges 

Validation 

CA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

CA Files 
Preliminary SIP 

CA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

CA Forwards 
Package 

CA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

CA Returns 
Package to 
Analyst 

CA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

CA Reviews SIP 
and DIP 

CA 

0 

0 

1 
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Pnaass 

Activity 

Peis£^»er 

Avg Queue 
Length 

I?l!n Queue 
Length 

Max Queue 
Length 

TSOKC_DIACAP_AsIs_Final 

CA Submits DIP 
to DAA 

CA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

CA Tasks 
Validator 

CA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

DAA 

Acknoledges 
Receipt of DIP 

DAA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

DAA Files 
Preliminary SIP 

DAA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

DAA Grants 
Accreditation 

DAA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

DAA Notifies 

PM 

DAA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

DAA Returns 
Approved DIP to 
PM 

DAA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

DAA Reviews 

CA Comments 

DAA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

DAA Reviews 
Package 

DAA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

DAA Reviews 
Preliminary SIP 

DAA 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

lAM Compiles 

CA Package 

lAM 

1.38 

0 

8 

TSOKC_DIACAP_AsIs_Final 

lAM Compiles 

SIP and DIP 

lAM 

1.88 

0 

7 

TSOKC_DIACAP_AsIs_Final 

lAM Confirms 
System is lAW 
DIP 

lAM 

1.48 

0 

6 

TSOKC_DIACAP_AsIs_Final 

lAM Corrects 

DIP 

lAM 

0.27 

0 

2 

TSOKC_DIACAP_AsIs_Final 

lAM Creates 
Preliminary Plan 

lAM 

2.07 

0 

8 

TSOKC_DIACAP_AsIs_Final 

lAM Creates 
Preliminary SIP 

lAM 

1.32 

0 

6 

TSOKC_DIACAP_AsIs_Final 

lAM Determines 
COA 

lAM 

0.08 

0 

1 

TSOKC_DIACAP_AsIs_Final 

lAM Determines 
COAl 

lAM 

0.06 

0 

1 

TSOKC_DIACAP_AsIs_Final 

lAM Determines 
Inheritance 

lAM 

2.11 

0 

7 

TSOKC_DIACAP_AsIs_Final 

lAM Determines 
MAC and CL 

lAM 

2.08 

0 

8 

TSOKC_DIACAP_AsIs_Final 

lAM Develops 
POAM 

lAM 

1.27 

0 

7 

TSOKC_DIACAP_AsIs_Final 

lAM Develops 
Requirements 

lAM 

2.04 

0 

7 

TSOKC_DIACAP_AsIs_Final 

lAM Executes 
the DIP 

lAM 

1.57 

0 

7 

TSOKC_DIACAP_AsIs_Final 

lAM Finalizes lA 
Controls 

lAM 

2.1 

0 

7 

TSOKC_DIACAP_AsIs_Final 

lAM Fixes 
Problems in Plan 

lAM 

0.19 

0 

1 

TSOKC_DIACAP_AsIs_Final 

lAM Identifies 
NonApplicable 

lAM 

2.12 

0 

7 

TSOKC_DIACAP_AsIs_Final 

lAM Identifies 
the IS 

lAM 

1.45 

0 

6 

TSOKC_DIACAP_AsIs_Final 

lAM Initiates 
Corrective Action 

lAM 

0.01 

0 

1 

TSOKC_DIACAP_AsIs_Final 

lAM Initiates 

DIP 

lAM 

2.09 

0 

8 

TSOKC_DIACAP_AsIs_Final 

lAM Lists 
Requirements 

lAM 

0.53 

0 

2 

TSOKC_DIACAP_AsIs_Final 

lAM Monitors lA 
Control 

lAM 

1.78 

0 

7 

TSOKC_DIACAP_AsIs_Final 

lAM Performs 
Final Review 

lAM 

1.38 

0 

8 

TSOKC_DIACAP_AsIs_Final 

lAM Registers IS 
with DON lA 

lAM 

1.42 

0 

6 

TSOKC_DIACAP_AsIs_Final 

lAM Reviews 
Discrepancies 

lAM 

0.26 

0 

1 

TSOKC_DIACAP_AsIs_Final 

lAM Reviews lA 
Baseline Controls 

lAM 

2.61 

0 

9 
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Pnaass 

Activity 

Performer 

Avg Queue 
Length 

Min Queue 
Length 

IVlax Queue 
Length 

TSOKC_DIACAP_AsIs_Final 

lAM Reviews lA 
Control Plan 

lAM 

1,57 

0 

7 

TSOKC_DIACAP_AsIs_Final 

lAM Reviews 
Validation Report 

lAM 

1.38 

0 

7 

TSOKC_DIACAP_AsIs_Final 

lAM Reviews the 
DIP 

lAM 

2.34 

0 

8 

TSOKC_DIACAP_AsIs_Final 

lAM Submits 
Package 

lAM 

1.25 

0 

7 

TSOKC_DIACAP_AsIs_Final 

lAM Submits 
Package1 

lAM 

1.46 

0 

6 

TSOKC_DIACAP_AsIs_Final 

lAM Submits 
Preliminary SIP 

lAM 

1.4 

0 

6 

TSOKC_DIACAP_AsIs_Final 

lAM Submits SIP 
and DIP to CAR 

lAM 

1.85 

0 

8 

TSOKC_DIACAP_AsIs_Final 

lAM Tests lA 
Control 

lAM 

1.76 

0 

7 

TSOKC_DIACAP_AsIs_Final 

PM Acknoledges 
Receipt of SIP 

PM 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

PM Passes DIP to 
lAM 

PM 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

PM Registers IS 
in DITPRDON 

PM 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

PM Reviews 
Preliminary SIP 

PM 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

PM Reviews the 
SIP and DIP 

PM 

0 

0 

1 

TSOKC_DIACAP_AsIs_Final 

Site 

lAM 

0.3 

0 

2 

TSOKC_DIACAP_AsIs_Final 

System 

lAM 

1.22 

0 

5 

Note: 

Red-marked Waiting Time values indicates "Activity has waiting time” 

Red-marked Usage values indicates "Usage crossed threshold" 
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APPENDIX B: “TO-BE” (VER. A) SAVVION PROCESS MODELER 

OUTPUT 


Simulation Results for TSOKC_DIACAP_ToBe_VerA_Final - (100 Packages) 


Duration | 37622:30:00 Time | | Duration hours: | | 37622.5 


Process Time And Cost 


Process 

ScenaHO 

Instance 

Total Cost {$) 

Waiting Time 
(Time) 

Total Time 
(Time) 


TSOKC_DIACAP_ToBe_VA_rinal 

(100 Packages) 

100 

2,683,126.38 

1369497:30:00 

1381150:30:00 



Grand 

Total 

2683126.38 

1369497:30:00 

1381150:30:00 

TSOKC DIACAP ToBe VerA Final 

Scenario 

(100 Packages) 

Instances 

100 


Activity 

Perl'ormer 

♦iecurs 

Waiting Time 
(Time) 

Time to 
Complete 
(Time) 

Total Time 
(Time) 

Work 

Time 

(Hours) 

Fired 

per 

Hour 

AWT 

Analyst Assesses Risk 

Any member of 
MCEN C&A 
Team 

116 

0:00:00 

1866:00:00 

1866:00:00 

1866.0 

0.0622 

16.09 

Analyst Drafts Decision 

Any member of 
MCEN C&A 
Team 

110 

0:00:00 

890:30:00 

890:30:00 

890.5 

0.1235 

8.10 

Analyst Forwards Package 

Any member of 
MCEN C&A 
Team 

110 

0:00:00 

223:00:00 

223:00:00 

223.0 

0.4933 

2.03 

Analyst Reviews Package 

Any member of 
MCEN C&A 
Team 

116 

0:00:00 

978:30:00 

978:30:00 

978.5 

0.1185 

8.44 

CA Acknoledges Receipt of SIP 

CA 

100 

10:30:00 

107:00:00 

117:30:00 

107.0 

0.9346 

1.07 

CA Acknowledges Validation 

CA 

102 

16:00:00 

109:00:00 

125:00:00 

109.0 

0.9358 

1.07 

CA Documents Discrepancies 

CA 

6 

0:00:00 

54:30:00 

54:30:00 

54.5 

0.1101 

9.08 

CA Files Preliminary SIP 

CA 

100 

13:00:00 

107:00:00 

120:00:00 

107.0 

0.9346 

1.07 

CA Forwards Package 

CA 

104 

9:00:00 

210:30:00 

219:30:00 

210.5 

0.4941 

2.02 

CA Returns Package to Analyst 

CA 

6 

0:00:00 

13:30:00 

13:30:00 

13.5 

0.4444 

2.25 

CA Reviews SIP and DIP 

CA 

110 

17:30:00 

940:30:00 

958:00:00 

940.5 

0.1170 

8.55 

CA Submits DIP to DAA 

CA 

104 

49:00:00 

210:30:00 

259:30:00 

210.5 

0.4941 

2.02 

CAR Acknoledges Receipt 

CA Rep 

113 

197:00:00 

120:00:00 

317:00:00 

120.0 

0.9417 

1.06 

CAR Acknoledges Receipt of SIP 

CA Rep 

100 

101:30:00 

107:00:00 

208:30:00 

107.0 

0.9346 

1.07 

CAR Acknowledges Receipt 

CA Rep 

101 

259:00:00 

108:00:00 

367:00:00 

108.0 

0.9352 

1.07 

CAR Analyzes Package 

CA Rep 

101 

328:30:00 

865:00:00 

1193:30:00 

865.0 

0.1168 

8.56 

CAR Analyzes Severity Codes 

CA Rep 

79 

340:30:00 

683:00:00 

1023:30:00 

683.0 

0.1157 

8.65 

CAR Determines COA 

CA Rep 

5 

0:00:00 

129:00:00 

129:00:00 

129.0 

0.0388 

25.80 
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Activity 

Perfiiner 

Occurs 

Waiting 

Time (Time) 

Time to 
Complete 
(Time) 

Total Time 
(Time) 

Work 

Time 

(Hours) 

Fired 

per 

Hour 

^T 

CAR Determines CertiGcation 

CA Rep 

106 

365:30:00 

1713:00:00 

2078:30:00 

1713.0 

0.0619 

■ 16.16' 

CAR Documents Corrective Action 

CA Rep 

1 

12:30:00 

6:30:00 

19:00:00 

6.5 

0.1538 

6.50 

CAR Documents Results 

CA Rep 

101 

393:00:00 

607:00:00 

1000:00:00 

607.0 

0.1664 

6.01 

CAR Makes Accreditation Rec 

CA Rep 

106 

381:30:00 

453:30:00 

835:00:00 

453.5 ■ 

0.2337 

4.28 

CAR Modifies Severity Codes 

CA Rep 

4 

10:30:00 

52:00:00 

62:30:00 

”52.0 ” 

0.0769 

13.00 

CAR Notifies CA 

CA Rep 

102 

266:00:00 

109:00:00 

375:00:00 

109.0 

0.9358 

1.07 

CAR Prioritizes Package 

CA Rep 

101 

340:30:00 

432:00:00 

772:30:00 

432.0 

0.2338 

4.28 

CAR Returns Package to PM 

CA Rep 

1 

21:00:00 

1:30:00 

22:30:00 

1.5 

0.6667 

1.50 

CAR Reviews Preliminary SIP 

CA Rep 

100 

152:30:00 

858:30:00 

1011:00:00 

858.5 

0.1165 

8.59 

CAR Reviews SIP and DIP 

CA Rep 

113 

121:00:00 

962:00:00 

1083:00:00 

962.0 

0.1175 

8.51 

CAR Submits PAckage to MCEN 

CA Rep 

106 

449:30:00 

214:30:00 

664:00:00 

214.5 

0.4942 

2.02 

CAR Submits SIP and DIP 

CA Rep 

107 

193:30:00 

114:30:00 

308:00:00 

114.5 

0.9345 

1.07 

CAR Tasks Validator 

CA Rep 

102 

250:00:00 

109:00:00 

359:00:00 

109.0 

0.9358 

1.07 

DAA Acknoledges Receipt of DIP 

DAA 

104 

60:30:00 

111:00:00 

171:30:00 

111.0 

0.9369 

1.07 

DAA Acknoledges Receipt of SIP 

DAA 

100 

29:00:00 

107:00:00 

136:00:00 

107.0 

0.9346 

1.07 

DAA Files Preliminary SIP 

DAA 

100 

24:00:00 

107:00:00 

131:00:00 

107.0 

0.9346 

1.07 

DAA Grants Accreditation 

DAA 

100 

123:00:00 

202:30:00 

325:30:00 

202.5 

0.4938 

2.03 

DAA Notifies PM 

DAA 

100 

192:30:00 

202:30:00 

395:00:00 

202.5 

0.4938 

2.03 

DAA Returns Approved DIP to PM 

DAA 

101 

69:30:00 

204:00:00 

273:30:00 

204.0 

0.4951 

2.02 

DAA Returns to Analyst 

DAA 

4 

33:00:00 

9:00:00 

42:00:00 

9.0 

0.4444 

2.25 

DAA Reviews CA Comments 

DAA 

104 

27:00:00 

888:00:00 

915:00:00 

888.0 

0.1171 

8.54 

DAA Reviews Package 

DAA 

104 

124:30:00 

1673:30:00 

1798:00:00 

1673.5 

0.0621 

16.09 

DAA Reviews Preliminary SIP 

DAA 

100 

54:30:00 

858:30:00 

913:00:00 

858.5 

0.1165 

8.59 

lAM Compiles CA Package 

lAM 

113 

40944:00:00 

2752:00:00 

43696:00:00 

2752.0 

0.0411 

24.35 

lAM Compiles SIP and DIP 

lAM 

107 

49331:30:00 

1719:00:00 

51050:30:00 

1719.0 

0.0622 

16.07 

lAM Confirms System is lAW DIP 

lAM 

102 

44002:30:00 

817:00:00 

44819:30:00 

817.0 

0.1248 

8.01 

lAM Corrects DIP 

lAM 

12 

5312:00:00 

105:00:00 

5417:00:00 

105.0 

0.1143 

8.75 

lAM Creates Preliminary Plan 

lAM 

119 

52733:30:00 

2864:00:00 

55597:30:00 

2864.0 

0.0416 

24.07 

lAM Creates Preliminary SIP 

lAM 

100 

42101:00:00 

2420:00:00 

44521:00:00 

2420.0 

0.0413 

24.20 

lAM Determines COA 

lAM 

4 

1220:30:00 

104:00:00 

1324:30:00 

104.0 

0.0385 

26.00 
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Aeti-vlty 

Peisformer 

Oiiiurs 

Waiting 

TimelTime) 

Time to 
Complete 
(Time) 

Total Time 
(Time) 

Work 

Time 

(HoilTSl 

Fired 
'• per 
' Hour 

AWT 

lAM Determines COAl 

lAM 

5 

1743:00:00 

129:00:00 

1872:00:00 

129.0 

0.0388 

25.80 

1AM Determines Inheritance 

lAM 

119 

54483:30:00 

956:00:00 

55439:30:00 

956.0 

0.1245 

8.03 

lAM Determines MAC and CL 

lAM 

119 

54764:00:00 

239:00:00 

55003:00:00 

239.0 

0.4979 

2.01 

lAM Develops POAM 

lAM 

91 

32938:00:00 

1469:30:00 

34407:30:00 

1469.5 

0.0619 

16.15 

1AM Develops Requirements 

lAM 

119 

50721:30:00 

4773:30:00 

55495:00:00 

4773.5 

0.0249 

^ 40.11 

lAM Finalizes lA Controls 

lAM 

119 

54209:00:00 

718:00:00 

54927:00:00 

718.0' 

0.1657 

*'6.03* ' 

lAM Fixes Problems in Plan 

lAM 

6 

2497:30:00 

66:30:00 

2564:00:00 

" 66.5 " 

0.0902 

■ 11.08 ■ 

lAM Identifies NonApplicable 

lAM 

119 

54245:30:00 

1912:00:00 

56157:30:00 

1912.0 

0.0622 

■ 16.07 ■ 

lAM Identifies the IS 

lAM 

100 

44242:00:00 

107:00:00 

44349:00:00 

107.0 

0.9346 

1.07 

lAM Initiates DIP 

lAM 

119 

54016:00:00 

956:00:00 

54972:00:00 

956.0 

0.1245 

8.03 

lAM Lists Requirements 

lAM 

30 

13817:00:00 

63:00:00 

13880:00:00 

63.0 

0.4762 

2.10 

lAM Monitors lA Control 

lAM 

114 

51076:30:00 

2758:00:00 

53834:30:00 

2758.0 

0.0413 

24.19 

lAM Performs Final Review 

lAM 

113 

41136:00:00 

914:30:00 

42050:30:00 

914.5 

0.1236 

8.09 

lAM Reviews Discrepancies 

lAM 

12 

4802:30:00 

105:00:00 

4907:30:00 

105.0 

0.1143 

8.75 

lAM Reviews lA Baseline Controls 

lAM 

149 

68009:00:00 

2401:00:00 

70410:00:00 

2401.0 

0.0621 

16.11 

lAM Reviews lA Control Plan 

lAM 

102 

46108:30:00 

823:30:00 

46932:00:00 

823.5 

0.1239 

8.07 

lAM Reviews Validation Report 

lAM 

101 

36664:30:00 

815:30:00 

37480:00:00 

815.5 

0.1239 

8.07 

lAM Reviews the DIP 

lAM 

133 

60268:30:00 

1068:00:00 

61336:30:00 

1068.0 

0.1245 

8.03 

1AM Submits Package 

lAM 

110 

38031:30:00 

223:00:00 

38254:30:00 

223.0 

0.4933 

2.03 

lAM Submits Packagel 

lAM 

102 

43856:00:00 

206:00:00 

44062:00:00 

206.0 

0.4951 

2.02 

lAM Submits Preliminary SIP 

lAM 

100 

44192:00:00 

202:30:00 

44394:30:00 

202.5 

0.4938 

2.03 

lAM Submits SIP and DIP to CAR 

lAM 

113 

51493:00:00 

229:00:00 

51722:00:00 

229.0 

0.4934 

2.03 

lAM Tests lA Control 

lAM 

114 

50218:00:00 

2758:00:00 

52976:00:00 

2758.0 

0.0413 

24.19 

lAO Applies Immediate Fixes 

Any member of 
lAO 

12 

0:00:00 

201:00:00 

201:00:00 

201.0 

0.0597 

16.75 

lAO Assembles DIP Components 

Any member of 
lAO 

133 

0:00:00 

1610:00:00 

1610:00:00 

1610.0 

0.0826 

12.11 

lAO Assigns Additional Controls 

Any member of 
lAO 

30 

0:00:00 

251:30:00 

251:30:00 

251.5 

0.1193 

8.38 

lAO Assigns lA Baseline Controls 

Any member of 
lAO 

119 

2:30:00 

2864:00:00 

2866:30:00 

2864.0 

0.0416 

24.07 

lAO Builds lA Controls into IS 

Any member of 
lAO 

114 

3:30:00 

1834:30:00 

1838:00:00 

1834.5 

0.0621 

16.09 

lAO Completes POAM 

Any member of 
lAO 

91 

3:00:00 

368:00:00 

371:00:00 

368.0 

0.2473 

4.04 

LAO Corrects DIP 

Any member of 
lAO 

12 

0:30:00 

105:00:00 

105:30:00 

105.0 

0.1143 

8.75 

lAO Creates lA Control List 

Any member of 
lAO 

119 

0:00:00 

950:00:00 

950:00:00 

950.0 

0.1253 

7.98 

LAO Creates Preliminary SIP 

Any member of 
lAO 

100 

0:00:00 

2420:00:00 

2420:00:00 

2420.0 

0.0413 

24.20 
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Activity' 

Perfumer 

Occurs 

Waiting 
Time (Time) 

Time to 
Complete 
(Time) 

Total Time 
(Time) 

WTTfk 

Time 

(Hoiirsl' 

Fired 
i: ii' per 

^ Hour 

- 

lAO Determines Actions Needed 

Any member of 
lAO 

91 

0:00:00 

732:00:00 

732:00:00 

732.0 

0.1243 

8.04 

lAO Determines COA 

Any member of 
lAO 

4 

0:00:00 

104:00:00 

104:00:00 

104.0 

0.0385 

26.00 

lAO Determines COAl 

Any member of 
lAO 

5 

0:00:00 

129:00:00 

129:00:00 

129.0 

0.0388 

25.80 

lAO Determines Fixes 

Any member of 
lAO 

114 

1:30:00 

1834:30:00 

1836:00:00 

1834.5 

0.0621 

16.09 

LAO Develops POAM 

Any member of 
lAO 

91 

0:00:00 

1469:30:00 

1469:30:00 

1469.5 

0.0619 

16.15 

lAO Develops Requirements 

Any member of 
lAO 

119 

0:00:00 

4773:30:00 

4773:30:00 

4773.5 

0.0249 

40.11 

lAO Documents Implementation 

Any member of 
lAO 

114 

0:00:00 

1378:30:00 

1378:30:00 

1378.5 

0.0827 

12.09 

LAO Documents Inheritance 

Any member of 
lAO 

119 

2:30:00 

477:00:00 

479:30:00 

477.0 

0.2495 

4.01 

LAO Documents NonApplicable 

Any member of 
lAO 

119 

0:00:00 

956:00:00 

956:00:00 

956.0 

0.1245 

8.03 

LAO Fixes Discrepancies 

Any member of 
lAO 

12 

0:00:00 

201:00:00 

201:00:00 

201.0 

0.0597 

16.75 

LAO Fixes Problems in Plan 

Any member of 
lAO 

6 

0:00:00 

66:30:00 

66:30:00 

66.5 

0.0902 

11.08 

lAO Incorporates LA Control Plan 

Any member of 
lAO 

114 

0:00:00 

1834:30:00 

1834:30:00 

1834.5 

0.0621 

16.09 

lAO Performs Final Review 

Any member of 
lAO 

113 

0:00:00 

914:30:00 

914:30:00 

914.5 

0.1236 

8.09 

LAO Reviews Documents 

Any member of 
lAO 

102 

0:00:00 

410:00:00 

410:00:00 

410.0 

0.2488 

4.02 

LAO Reviews Validation Report 

Any member of 
lAO 

101 

0:00:00 

815:30:00 

815:30:00 

815.5 

0.1239 

8.07 

lAO Updates Artifacts 

Any member of 
lAO 

11 

0:00:00 

96:30:00 

96:30:00 

96.5 

0.1140 

8.77 

lAO Updates lA Control Plan 

Any member of 
lAO 

12 

0:00:00 

101:00:00 

101:00:00 

101.0 

0.1188 

8.42 

MCEN Acknowledges Receipt 

Any member of 
MCEN C&A 
Team 

106 

0:00:00 

113:30:00 

113:30:00 

113.5 

0.9339 

1.07 

MCEN Prioritizes Package 

Any member of 
MCEN C&A 
Team 

106 

0:00:00 

856:00:00 

856:00:00 

856.0 

0.1238 

8.08 

PM Corrects DIP 

PM 

12 

43:00:00 

105:00:00 

148:00:00 

105.0 

0.1143 

8.75 

PM Creates Preliminary Plan 

PM 

119 

201:00:00 

2864:00:00 

3065:00:00 

2864.0 

0.0416 

24.07 

PM Creates Preliminary SIP 

PM 

100 

50:00:00 

2420:00:00 

2470:00:00 

2420.0 

0.0413 

24.20 

PM Determines COA 

PM 

4 

15:30:00 

104:00:00 

119:30:00 

104.0 

0.0385 

26.00 

PM Determines COAl 

PM 

5 

0:00:00 

129:00:00 

129:00:00 

129.0 

0.0388 

25.80 

PM Develops POAM 

PM 

91 

562:00:00 

1469:30:00 

2031:30:00 

1469.5 

0.0619 

16.15 

PM Executes tbe DIP 

PM 

102 

303:00:00 

823:30:00 

1126:30:00 

823.5 

0.1239 

8.07 

PM Initiates Corrective Action 

PM 

1 

11:00:00 

6:30:00 

17:30:00 

6.5 

0.1538 

6.50 

PM Registers IS in DITPRDON 

PM 

100 

119:00:00 

202:30:00 

321:30:00 

202.5 

0.4938 

2.03 

PM Registers IS with DON lA 

PM 

100 

619:00:00 

202:30:00 

821:30:00 

202.5 

0.4938 

2.03 

PM Reviews Package 

PM 

104 

315:00:00 

841:30:00 

1156:30:00 

841.5 

0.1236 

8.09 

PM Reviews Validation Report 

PM 

101 

407:00:00 

815:30:00 

1222:30:00 

815.5 

0.1239 

8.07 

PM Reviews the SIP and DIP 

PM 

104 

92:00:00 

888:00:00 

980:00:00 

888.0 

0.1171 

8.54 
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Activity 

Performer 

Occurs 

Waiting 

Time (Time) 

Time to 
Complete 
(Time) 

Total Time 
(Time) 

Work 

Time 

(Hours) 

Fired 

per 

Hour 

^T 

PM Submits Package to CAR 

PM 

101 

269:30:00 

204:00:00 

473:30:00 

' 204.0 ■ 

0.4951 

" 2.02 

Reviewer Acknoledges Receipt 

Any member of 
MCEN C&A 
Team 

107 

0:00:00 

114:30:00 

114:30:00 

114.5 

0.9345 

1.07 

Reviewer Analyzes DIP 

Any member of 
MCEN C&A 
Team 

107 

0:00:00 

4306:00:00 

4306:00:00 

4306.0 

0.0248 

40.24 

Reviewer Documents Comments 

Any member of 
MCEN C&A 
Team 

107 

0:00:00 

6446:00:00 

6446:00:00 

6446.0 

0.0166 

60.24 

Reviewer Submits DIP to CA 

Any member of 
MCEN C&A 
Team 

107 

0:00:00 

216:00:00 

216:00:00 

216.0' 

0.4954 

2.02 " 

Site 

lAM 

20 

8609:30:00 

48:00:00 

8657:30:00 

48.0 

0.4167 

2.40 

System 

lAM 

80 

34928:00:00 

86:00:00 

35014:00:00 

86.0 

0.9302 

1.08 

UR Acknoledges Receipt of SIP 

User Rep 

100 

85:30:00 

107:00:00 

192:30:00 

107.0 

0.9346 

1.07 

UR Develops POAM 

User Rep 

91 

114:00:00 

1469:30:00 

1583:30:00 

1469.5 

0.0619 

16.15 

UR Reviews Package 

User Rep 

110 

206:30:00 

890:30:00 

1097:00:00 

890.5 

0.1235 

8.10 

UR Reviews Preliminary SIP 

User Rep 

100 

79:00:00 

858:30:00 

937:30:00 

858.5 

0.1165 

8.59 

UR Reviews the SIP and DIP 

User Rep 

107 

30:00:00 

915:00:00 

945:00:00 

915.0 

0.1169 

8.55 

Val Identifies Vulnerabilities 

Validator 

114 

7512:00:00 

458:00:00 

7970:00:00 

458.0 

0.2489 

4.02 

Validator Analyzes Test Results 

Validator 

114 

7727:00:00 

965:00:00 

8692:00:00 

965.0 

0.1181 

8.46 

Validator Assesses Risk 

Validator 

99 

6224:00:00 

1598:00:00 

7822:00:00 

1598.0 

0.0620 

16.14 

Validator Assigns Severity Codes 

Validator 

99 

5826:00:00 

796:00:00 

6622:00:00 

796.0 

0.1244 

8.04 

Validator Compiles Test Results 

Validator 

101 

6576:00:00 

815:30:00 

7391:30:00 

815.5 

0.1239 

8.07 

Validator Creates Scorecard 

Validator 

101 

6818:00:00 

405:00:00 

7223:00:00 

405.0 

0.2494 

4.01 

Validator Determines Fixes 

Validator 

114 

7534:30:00 

1834:30:00 

9369:00:00 

1834.5 

0.0621 

16.09 

Validator Determines POAM 

Validator 

99 

5255:00:00 

399:30:00 

5654:30:00 

399.5 

0.2478 

4.04 

Validator Documents Risk Levels 

Validator 

99 

5886:30:00 

598:00:00 

6484:30:00 

598.0 

0.1656 

6.04 

Validator Documents Test Results 

Validator 

114 

7452:30:00 

1378:30:00 

8831:00:00 

1378.5 

0.0827 

12.09 

Validator Evaluates Impact 

Validator 

94 

5694:30:00 

770:00:00 

6464:30:00 

770.0 

0.1221 

8.19 

Validator Maps Vulnerabilities 

Validator 

113 

7326:30:00 

2733:30:00 

10060:00:00 

2733.5 

0.0413 

24.19 

Validator Notes Discrepancies 

Validator 

114 

7514:30:00 

694:30:00 

8209:00:00 

694.5 

0.1641 

6.09 

Validator Notifies PM 

Validator 

4 

278:30:00 

9:00:00 

287:30:00 

9.0 

0.4444 

2.25 

Validator Performs GAP Analysis 

Validator 

114 

7454:00:00 

1834:30:00 

9288:30:00 

1834.5 

0.0621 

16.09 

Validator Reviews CA Plan 

Validator 

120 

6836:00:00 

1926:00:00 

8762:00:00 

1926.0 

0.0623 

16.05 
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Activity 

Performer 

Occurs 

Waiting 

Time (Time) 

Time to 
Complete 
(Time) 

Total Time 
(Time) 

Work 

Time 

(Hours) 

Fired 

per 

Hour 

^T 

Validator Reviews Control Plan 

Validator 

120 

7143:00:00 

1017:00:00 

8160:00:00 

1017.0 

0.1180 

" 8.48 

Validator Reviews Scorecard 

Validator 

101 

7045:00:00 

405:00:00 

7450:00:00 

405.0 

0.2494 

4.01 

Validator Submits Report 

Validator 

101 

5253:00:00 

204:00:00 

5457:00:00 

204.0 

0.4951 

2.02 

Validator Validates lA Controls 

Validator 

114 

6854:00:00 

2758:00:00 

9612:00:00 

2758.0 

0.0413 

24.19 









Times 

Times 

ASVT 

Resource 

Unit 

Cost/llnit 

Threshold 

Usage 


Fired 

Med 

(HotM|M 







(Sum) 

/Hour 

(SuiM 

CA 

Hour 

0 

0 

1752:30:00 

0 

”632 

0.0168 

2.77294 

CA Rep 

Hour 

28.45 

0 

7645:00:00 

217500.25 

1549 

0.0412 

4.93544 

DAA 

Hour 

0 

0 

4363:00:00 

0 

917 

0.0244 

4.75791 

lAM 

Hour 

28.45 

0 

34808:30:00 

990301.83 

2866 

0.0762 

12.1453 

Any member of lAO 

Hour 

23.74 

0 

26897:30:00 

638546.65 

1977 

0.0525 

13.6052 

Any member of MCEN C&A Team 

Hour 

0 

0 

16010:00:00 

0 

1092 

0.0290 

14.6612 

PM 

Hour 

28.45 

0 

11075:30:00 

315097.97 

1044 

0.0277 

10.6087 

User Rep 

Hour 

12.95 

0 

4240:30:00 

54914.48 

508 

0.0135 

8.34744 

Validator 

Hour 

21.61 

0 

21599:30:00 

466765.2 

2049 

0.0545 

10.5415 


Performers queue length and utilization 



Aig 

Min 

Max 

Utilized) %) 

Idle( %) 

CA 

0 

0 

2 

4.66 

95.34 

CA Rep 

0.11 

0 

6 

20.32 

79.68 

DAA 

0.02 

0 

3 

11.6 

88.4 

lAM 

32.77 

0 

68 

92.52 

7.48 

Any member of lAO 

0 

0 

1 

17.87 

82.13 

Any member of MCEN C&A Team 

0 

0 

0 

0.21 

99.79 

PM 

0.08 

0 

7 

29.44 

70.56 

User Rep 

0.01 

0 

3 

11.27 

88.73 

Validator 

3.41 

0 

26 

57.41 

42.59 

Bottlenecks 


Preeess 

Activity 

Performer 

Avg Queue 
Length 

Min Queue 
Length 

Max Queue 
Length 

TSOKC_DIACAP_ToBe_VA_rinal 

CA 

Acknoledges 
Receipt of SIP 

CA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

CA 

Acknowledges 

Validation 

CA 

0 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

CA Files 
Preliminary SIP 

CA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

CA Forwards 
Package 

CA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

CA Reviews 

SIP and DIP 

CA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

CA Submits 

DIP to DAA 

CA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR 

Acknoledges 

Receipt 

CA Rep 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR 

Acknoledges 
Receipt of SIP 

CA Rep 

0 

0 

1 
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Process 

Activity 

Performer 

Avg Queue 
b«^th 

Min Queue 
Length 

Max Queue 
Length 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR 

Acknowledges 

Receipt 

CA Rep 

O.OI 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR Analyzes 
Package 

CA Rep 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR Analyzes 
Severity Codes 

CA Rep 

0.01 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR 

Determines 

Certification 

CA Rep 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR 

Documents 

Corrective 

Action 

CA Rep 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR 

Documents 

Results 

CA Rep 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR Makes 
Accreditation 

Rec 

CA Rep 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR Modifies 
Severity Codes 

CA Rep 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR Notifies 

CA 

CA Rep 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR Prioritizes 
Package 

CA Rep 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR Returns 
Package to PM 

CA Rep 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR Reviews 
Preliminary SIP 

CA Rep 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR Reviews 
SIP and DIP 

CA Rep 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR Submits 
PAckage to 
MCEN 

CA Rep 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR Submits 

SIP and DIP 

CA Rep 

0.01 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

CAR Tasks 
Validator 

CARep 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

DAA 

Acknoledges 
Receipt of DIP 

DAA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

DAA 

Acknoledges 
Receipt of SIP 

DAA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

DAA Files 
Preliminary SIP 

DAA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

DAA Grants 
Accreditation 

DAA 

0 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

DAA Notifies 

PM 

DAA 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

DAA Returns 
Approved DIP 
to PM 

DAA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

DAA Returns to 
Analyst 

DAA 

0 

0 

1 
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Process 

Activity 

Performer 

Avg Queue 

Min Queue 
Length 

Max Queue 
Length 

TSOKC_DIACAP_ToBe_VA_rinal 

DAA Reviews 
CA Comments 

DAA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

DAA Reviews 
Package 

DAA 

0 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

DAA Reviews 
Preliminary SIP 

DAA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Compiles 
CA Package 

lAM 

1.09 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Compiles 
SIP and DIP 

lAM 

1.31 

0 

6 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Confirms 
System is lAW 
DIP 

lAM 

1.17 

0 

6 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Corrects 
DIP 

1AM 

0.14 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Creates 
Preliminai'y 

Plan 

lAM 

1.4 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Creates 
Preliminary SIP 

lAM 

1.12 

0 

4 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM 

Determines 

COA 

lAM 

0.03 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM 

Determines 

COAl 

lAM 

0.05 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM 

Determines 

Inheritance 

1AM 

1.45 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM 

Determines 
MAC and CL 

lAM 

1.46 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Develops 
POAM 

lAM 

0.88 

0 

4 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Develops 
Requirements 

lAM 

1.35 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Finalizes 
lA Controls 

lAM 

1.44 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

1AM Fixes 
Problems in 

Plan 

1AM 

0.07 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Identifies 
NonApplicable 

lAM 

1.44 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Identifies 
the IS 

lAM 

1.18 

0 

4 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Initiates 
DIP 

lAM 

1.44 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Lists 
Requirements 

lAM 

0.37 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Monitors 
lA Control 

lAM 

1.36 

0 

7 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Perfonns 
Final Review 

lAM 

1.09 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Reviews 
Discrepancies 

lAM 

0.13 

0 

1 
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Process 

Activity 

Performer 

Avg Queue 

Min Queue 
Length 

Max Queue 
Length 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Reviews 
lA Baseline 
Controls 

lAM 

1.81 

0 

7 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Reviews 
lA Control Plan 

lAM 

1.23 

0 

6 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Reviews 
Validation 
Report 

lAM 

0.97 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Reviews 
the DIP 

lAM 

1.6 

0 

6 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Submits 
Package 

lAM 

1.01 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Submits 
Package1 

lAM 

1.17 

0 

6 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Submits 
Preliminary SIP 

lAM 

1.17 

0 

4 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Submits 

SIP and DIP to 
CAR 

lAM 

1.37 

0 

7 

TSOKC_DIACAP_ToBe_VA_rinal 

lAM Tests lA 
Control 

lAM 

1.33 

0 

7 

TSOKC_DIACAP_ToBe_VA_rinal 

lAO Assigns lA 
Baseline 
Controls 

Any 

member of 
lAO 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

lAO Builds lA 
Controls into IS 

Any 

member of 
lAO 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

lAO Completes 
POAM 

Any 

member of 
lAO 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

lAO Corrects 
DIP 

Any 

member of 
lAO 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

lAO Determines 
Fixes 

Any 

member of 
lAO 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

lAO Documents 
Inheritance 

Any 

member of 
lAO 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Corrects 

DIP 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Creates 
Preliminary 

Plan 

PM 

0.01 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Creates 
Preliminary SIP 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Determines 
COA 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Develops 
POAM 

PM 

0.01 

0 

3 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Executes 
the DIP 

PM 

0.01 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Initiates 
Corrective 
Action 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Registers IS 
in DITPRDON 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Registers IS 
with DON lA 

PM 

0.02 

0 

1 


89 



































Process 

Activity 

Performer 

Avg Queue 

Min Queue 
Length 

Max Queue 
Length 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Reviews 
Package 

PM 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Reviews 
Validation 
Report 

PM 

0.01 

0 

3 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Reviews the 
SIP and DIP 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

PM Submits 
Package to CAR 

PM 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VA_rinal 

Site 

lAM 

0.23 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

System 

lAM 

0.93 

0 

4 

TSOKC_DIACAP_ToBe_VA_rinal 

UR 

Acknoledges 
Receipt of SIP 

User Rep 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

UR Develops 
POAM 

User Rep 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

UR Reviews 
Package 

User Rep 

0.01 

0 

3 

TSOKC_DIACAP_ToBe_VA_rinal 

UR Reviews 
Preliminary SIP 

User Rep 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

UR Reviews the 
SIP and DIP 

User Rep 

0 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

Val Identifies 
Vulnerabilities 

Validator 

0.2 

0 

7 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 
Analyzes Test 
Results 

Validator 

0.21 

0 

7 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 
Assesses Risk 

Validator 

0.17 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 
Assigns 
Severity Codes 

Validator 

0.15 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 
Compiles Test 
Results 

Validator 

0.17 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 

Creates 

Scorecard 

Validator 

0.18 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 

Determines 

Fixes 

Validator 

0.2 

0 

7 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 

Determines 

POAM 

Validator 

0.14 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 
Documents Risk 
Levels 

Validator 

0.16 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 
Documents Test 
Results 

Validator 

0.2 

0 

7 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 

Evaluates 

Impact 

Validator 

0.15 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator Maps 
Vulnerabilities 

Validator 

0.19 

0 

6 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator Notes 
Discrepancies 

Validator 

0.2 

0 

7 
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Process 

Activity 

Performer 

Avg Queue 
Length 

Min Queue 
Length 

Max Queue 
Length 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 
Notifies PM 

Validator 

0.01 

0 

1 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 
Performs GAP 
Analysis 

Validator 

0.2 

0 

7 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 
Reviews CA 
Plan 

Validator 

0.18 

0 

7 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 
Reviews 
Control Plan 

Validator 

0.19 

0 

7 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 

Reviews 

Scorecard 

Validator 

0.19 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 
Submits Report 

Validator 

0.14 

0 

5 

TSOKC_DIACAP_ToBe_VA_rinal 

Validator 
Validates lA 
Controls 

Validator 

0.18 

0 

7 

Note: 

Red-maiked Waiting Time values indicates "Activity has waiting time" 

Red-marked Usage values indicates "Usage crossed threshold" 
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APPENDIX C: “TO-BE” (VER. B) SAVVION PROCESS MODELER 

OUTPUT 


Simulation Results for TSOKC_DIACAP_ToBe_VerB_Final - (100 Packages) 


Duration 

35092:30:00 Time 


Duration 

hours: 

35092.5 

Process Time And Cost 


Process 

Scenario 

Instance 

To^^ost 

Waiting Time 
(Time) 

Total Time 
(Time) 

TSOKC_DIACAP_ToBe_VB_rinal 

(100 

Packages) 

100 

1,977,773.03 

1219222:00:00 

1237158:00:00 



Grand 

Total 

1977773.03 

1219222:00:00 

1237158:00:00 

TSOKC_DIACAP_ToBe_VerB_Final 

Scenario 

(100 Packages) 

Instances 

100 


Activity 

Performer 

Occurs 

Waiting 

Time 

(Time) 

Time to 
Complete 
(Time) 

Total Time 
(Time) 

1 

Work 

Time 

(Hours) 

Fired/Hour 

AWT 

Analyst Assesses Risk 

Any member 
ofMCEN 
C&A Team 

116 

0:00:00 

1846:00:00 

1846:00:00 

1846.0 

0.0628 

15.91 

Analyst Drafts Decision 

Any member 
ofMCEN 
C&A Team 

110 

0:00:00 

867:30:00 

867:30:00 

867.5 

0.1268 

7.89 

Analyst Forwards Package 

Any member 
ofMCEN 
C&A Team 

110 

0:00:00 

219:00:00 

219:00:00 

219.0 

0.5023 

1.99 

Analyst Reviews Package 

Any member 
OfMCEN 
C&A Team 

116 

0:00:00 

966:30:00 

966:30:00 

966.5 

0.1200 

8.33 

CA Acknoledges Receipt of SIP 

CA 

100 

3:00:00 

104:30:00 

107:30:00 

104.5 

0.9569 

1.05 

CA Acknowledges Validation 

CA 

102 

15:30:00 

107:30:00 

123:00:00 

107.5 

0.9488 

1.05 

CA Documents Discrepancies 

CA 

6 

0:00:00 

49:00:00 

49:00:00 

49.0 

0.1224 

8.17 

CA Files Preliminary SIP 

CA 

100 

12:00:00 

104:30:00 

116:30:00 

104.5 

0.9569 

1.05 

CA Forwards Package 

CA 

104 

7:00:00 

206:00:00 

213:00:00 

206.0 

0.5049 

1.98 

CA Returns Package to Analyst 

CA 

6 

0:00:00 

12:30:00 

12:30:00 

12.5 

0.4800 

2.08 

CA Reviews SIP and DIP 

CA 

110 

26:00:00 

920:30:00 

946:30:00 

920.5 

0.1195 

8.37 

CA Submits DIP to DAA 

CA 

104 

39:00:00 

206:00:00 

245:00:00 

206.0 

0.5049 

1.98 

CAR Acknoledges Receipt 

Any member 
ofMCEN 
C&A Team 

119 

0:00:00 

123:00:00 

123:00:00 

123.0 

0.9675 

1.03 

CAR Acknoledges Receipt of SIP 

Any member 
ofMCEN 
C&A Team 

100 

0:00:00 

104:30:00 

104:30:00 

104.5 

0.9569 

1.05 

CAR Acknowledges Receipt 

Any member 
OfMCEN 
C&A Team 

101 

0:00:00 

106:00:00 

106:00:00 

106.0 

0.9528 

1.05 

CAR Analyzes Package 

Any member 
ofMCEN 
C&A Team 

101 

0:00:00 

843:30:00 

843:30:00 

843.5 

0.1197 

8.35 

CAR Analyzes Severity Codes 

Any member 
ofMCEN 
C&A Team 

85 

0:00:00 

709:30:00 

709:30:00 

709.5 

0.1198 

8.35 

CAR Determines COA 

Any member 
OfMCEN 
C&A Team 

5 

0:00:00 

123:00:00 

123:00:00 

123.0 

0.0407 

24.60 

CAR Determines Certification 

Any member 
OfMCEN 
C&A Team 

106 

0:00:00 

1678:00:00 

1678:00:00 

1678.0 

0.0632 

15.83 
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Activity 

Performer 

Occurs 

Waiting 

Time 

(Time) 

Time t<» 
Complete 
(Time) 

Total Time 
(Time) 

Work 

Time 

(Hours) 

Fired/Hour 

AWT 

CAR Documents Corrective Action 

Any member 
of MCEN 
C&A Team 


0:00:00 

5:00:00 

5:00:00 

5.0 )■ 

1 0.2000 

5.00 

CAR Documents Results 

Any member 
of MCEN 
C&A Team 

101 

0:00:00 

598:30:00 

598:30:00 

598.5 _ 

0.1688 

_5.93_ 

CAR Makes Accreditation Rec 

Any member 
of MCEN 
C&A Team 

106 

0:00:00 

441:00:00 

441:00:00 

441.0 

0.2404 

4.16 

CAR Modifies Severity Codes 

Any member 
of MCEN 
C&A Team 

5 

0:00:00 

61:00:00 

61:00:00 

61.0 

0.0820 

12.20 

CAR Notifies CA 

Any member 
of MCEN 
C&A Team 

102 

0:00:00 

107:30:00 

107:30:00 

107.5 

0.9488 

1.05 

CAR Prioritizes Package 

Any member 
of MCEN 
C&A Team 

101 

0:00:00 

790:30:00 

790:30:00 

790.5 

0.1278 

7.83 

CAR Returns Package to PM 

Any member 
of MCEN 
C&A Team 


0:00:00 

1:30:00 

1:30:00 

1.5 

0.6667 

1.50 

CAR Reviews Preliminary SIP 

Any member 
of MCEN 
C&A Team 

100 

0:00:00 

833:00:00 

833:00:00 

833.0 

0.1200 

8.33 

CAR Reviews SIP and DIP 

Any member 
of MCEN 
C&A Team 

119 

0:00:00 

1886:00:00 

1886:00:00 

1886.0 

0.0631 

15.85 

CAR Submits PAckage to MCEN 

Any member 
of MCEN 
C&A Team 

106 

0:00:00 

211:00:00 

211:00:00 

211.0 

0.5024 

1.99 

CAR Submits SIP and DIP 

Any member 
of MCEN 
C&A Team 

107 

0:00:00 

112:30:00 

112:30:00 

112.5 

0.9511 

1.05 

CAR Tasks Validator 

Any member 
of MCEN 
C&A Team 

102 

0:00:00 

107:30:00 

107:30:00 

107.5 

0.9488 

1.05 

DAA Acknoledges Receipt of DIP 

DAA 

104 

87:30:00 

109:00:00 

196:30:00 

109.0 

0.9541 

1.05 

DAA Acknoledges Receipt of SIP 

DAA 

100 

33:00:00 

104:30:00 

137:30:00 

104.5 

0.9569 

1.05 

DAA Files Preliminary SIP 

DAA 

100 

57:00:00 

104:30:00 

161:30:00 

104.5 

0.9569 

1.05 

DAA Grants Accreditation 

DAA 

100 

198:30:00 

198:00:00 

396:30:00 

198.0 

0.5051 

1.98 

DAA Notifies PM 

DAA 

100 

274:00:00 

198:00:00 

472:00:00 

198.0 

0.5051 

1.98 

DAA Returns Approved DIP to PM 

DAA 

101 

103:00:00 

199:30:00 

302:30:00 

199.5 

0.5063 

1.98 

DAA Returns to Analyst 

DAA 

4 

0:00:00 

8:30:00 

8:30:00 

8.5 

0.4706 

2.13 

DAA Reviews CA Comments 

DAA 

104 

42:30:00 

866:30:00 

909:00:00 

866.5 

0.1200 

8.33 

DAA Reviews Package 

DAA 

104 

185:30:00 

1647:00:00 

1832:30:00 

1647.0 

0.0631 

15.84 

DAA Reviews Preliminary SIP 

DAA 

100 

67:30:00 

833:00:00 

900:30:00 

833.0 

0.1200 

8.33 

lAM CompUes CA Package 

lAM 

113 

43008:30:00 

2734:30:00 

45743:00:00 

2734.5 

0.0413 

24.20 

lAM Compiles SIP and DIP 

lAM 

107 

47649:30:00 

1700:30:00 

49350:00:00 

1700.5 

0.0629 

15.89 

lAM Confirms System is lAW DIP 

lAM 

102 

43327:00:00 

809:30:00 

44136:30:00 

809.5 

0.1260 

7.94 

lAM Corrects DIP 

lAM 

18 

7837:00:00 

145:00:00 

7982:00:00 

145.0 

0.1241 

8.06 

lAM Creates Preliminary Plan 

lAM 

119 

48896:30:00 

2838:00:00 

51734:30:00 

2838.0 

0.0419 

23.85 

LAM Creates Preliminary SIP 

lAM 

100 

39494:30:00 

2377:00:00 

41871:30:00 

2377.0 

0.0421 

23.77 

lAM Determines COA 

lAM 

4 

1486:30:00 

97:30:00 

1584:00:00 

97.5 

0.0410 

24.38 

lAM Determines COAl 

lAM 

5 

1881:00:00 

123:00:00 

2004:00:00 

123.0 

0.0407 

24.60 

lAM Determines Inheritance 

lAM 

119 

51880:00:00 

939:30:00 

52819:30:00 

939.5 

0.1267 

7.89 

lAM Determines MAC and CL 

lAM 

119 

51650:00:00 

236:30:00 

51886:30:00 

236.5 

0.5032 

1.99 
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Activity 

Performer 

Occurs 

Wartmg 

Time 

(Time) 

Time tu 
Complete 
(Time) 

Total Time 
(Time) 

Work 

Time 

(Hours) 

Fired/Hour 

AWT 

lAM Develops POAM 

lAM 

91 

37132:00:00 

1446:00:00 

38578:00:00 

1446.0 

0.0629 

15.89 

lAM Develops Requirements 

lAM 

119 

47679:00:00 

4720:00:00 

52399:00:00 

4720.0 

0.0252 

39.66 

lAM Finalizes lA Controls 

lAM 

119 

51915:00:00 

716:30:00 

52631:30:00 

716.5 

0.1661 

6.02 

lAM Fixes Problems in Plan 

lAM 

13 

5494:30:00 

136:00:00 

5630:30:00 

136.0 

0.0956 

10.46 

1AM Identifies NonApplicable 

lAM 

119 

51599:30:00 

1886:00:00 

53485:30:00 

1886.0 

0.0631 

15.85 

lAM Identifies the IS 

lAM 

100 

41430:00:00 

104:30:00 

41534:30:00 

104.5 

0.9569 

1.05 

lAM Initiates DIP 

lAM 

119 

51054:00:00 

939:30:00 

51993:30:00 

939.5 

0.1267 

7.89 

lAM Lists Requirements 

lAM 

30 

13348:00:00 

61:00:00 

13409:00:00 

61.0 

0.4918 

2.03 

lAM Monitors lA Control 

lAM 

114 

49563:30:00 

2726:30:00 

52290:00:00 

2726.5 

0.0418 

23.92 

lAM Performs Final Review 

lAM 

113 

43723:30:00 

898:30:00 

44622:00:00 

898.5 

0.1258 

7.95 

lAM Reviews Discrepancies 

lAM 

12 

4807:30:00 

102:00:00 

4909:30:00 

102.0 

0.1176 

8.50 

lAM Reviews lA Baseline Controls 

lAM 

149 

64671:30:00 

2386:30:00 

67058:00:00 

2386.5 

0.0624 

16.02 

lAM Reviews lA Control Plan 

lAM 

102 

44437:30:00 

800:00:00 

45237:30:00 

800.0 

0.1275 

7.84 

lAM Reviews Validation Report 

lAM 

101 

42051:30:00 

790:30:00 

42842:00:00 

790.5 

0.1278 

7.83 

lAM Reviews the DIP 

lAM 

133 

58383:00:00 

1066:00:00 

59449:00:00 

1066.0 

0.1248 

8.02 

lAM Submits Package 

lAM 

110 

42874:30:00 

219:00:00 

43093:30:00 

219.0 

0.5023 

1.99 

lAM Submits Packagel 

lAM 

102 

43621:30:00 

202:00:00 

43823:30:00 

202.0 

0.5050 

1.98 

lAM Submits Preliminary SIP 

lAM 

100 

41196:30:00 

198:00:00 

41394:30:00 

198.0 

0.5051 

1.98 

lAM Submits SIP and DIP to CAR 

lAM 

119 

52826:00:00 

236:30:00 

53062:30:00 

236.5 

0.5032 

1.99 

lAM Tests lA Control 

lAM 

114 

48959:30:00 

2726:30:00 

51686:00:00 

2726.5 

0.0418 

23.92 

lAO Applies Immediate Fixes 

Any member 
oflAO 

12 

0:00:00 

198:00:00 

198:00:00 

198.0 

0.0606 

16.50 

lAO Assembles DIP Components 

Any member 
oflAO 

133 

0:30:00 

1596:30:00 

1597:00:00 

1596.5 

0.0833 

12.00 

lAO Assigns Additional Controls 

Any member 
oflAO 

30 

0:00:00 

241:00:00 

241:00:00 

241.0 

0.1245 

8.03 

lAO Assigns lA Baseline Controls 

Any member 
oflAO 

119 

0:00:00 

2838:00:00 

2838:00:00 

2838.0 

0.0419 

23.85 

lAO Builds lA Controls into IS 

Any member 
oflAO 

114 

2:30:00 

1816:00:00 

1818:30:00 

1816.0 

0.0628 

15.93 

lAO Completes POAM 

Any member 
oflAO 

91 

0:00:00 

360:00:00 

360:00:00 

360.0 

0.2528 

3.96 

lAO Corrects DIP 

Any member 
oflAO 

18 

0:00:00 

145:00:00 

145:00:00 

145.0 

0.1241 

8.06 

lAO Creates lA Control List 

Any member 
oflAO 

119 

0:00:00 

947:00:00 

947:00:00 

947.0 

0.1257 

7.96 

lAO Creates Preliminary SIP 

Any member 
oflAO 

100 

0:00:00 

2377:00:00 

2377:00:00 

2377.0 

0.0421 

23.77 

LAO Determines Actions Needed 

Any member 
oflAO 

91 

0:00:00 

724:00:00 

724:00:00 

724.0 

0.1257 

7.96 

lAO Determines COA 

Any member 
oflAO 

4 

0:00:00 

97:30:00 

97:30:00 

97.5 

0.0410 

24.38 

lAO Determines COAl 

Any member 
oflAO 

5 

0:00:00 

123:00:00 

123:00:00 

123.0 

0.0407 

24.60 

lAO Determines Fixes 

Any member 
oflAO 

114 

0:00:00 

1816:00:00 

1816:00:00 

1816.0 

0.0628 

15.93 

lAO Develops POAM 

Any member 
oflAO 

91 

0:00:00 

1446:00:00 

1446:00:00 

1446.0 

0.0629 

15.89 

lAO Develops Requirements 

Any member 
oflAO 

119 

0:00:00 

4720:00:00 

4720:00:00 

4720.0 

0.0252 

39.66 

lAO Documents Implementation 

Any member 
oflAO 

114 

0:00:00 

1360:00:00 

1360:00:00 

1360.0 

0.0838 

11.93 
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Activity 

Performer 

Occurs 

Waiting 

Time 

(Time) 

Time t<» 
Compiete 
(Time) 

Total Time 
(Time) 

Wftrk 

Time 

(Hours) 

Fired/Hour 

AWT 

lAO Documents Inheritance 

Any member 
oflAO 

119 

0:00:00 

474:30:00 

474:30:00 

474.5 

0.2508 

3.99 

lAO Documents NonApplicable 

Any member 
oflAO 

119 

0:00:00 

939:30:00 

939:30:00 

939.5 

0.1267 

7.89 

lAO Fixes Discrepancies 

Any member 
oflAO 

12 

0:00:00 

198:00:00 

198:00:00 

198.0 

0.0606 

16.50 

lAO Fixes Problems in Plan 

Any member 
oflAO 

13 

0:00:00 

136:00:00 

136:00:00 

136.0 

0.0956 

10.46 

lAO Incorporates lA Control Plan 

Any member 
oflAO 

114 

0:00:00 

1816:00:00 

1816:00:00 

1816.0 

0.0628 

15.93 

lAO Performs Final Review 

Any member 
oflAO 

113 

0:00:00 

898:30:00 

898:30:00 

898.5 

0.1258 

7.95 

lAO Reviews Documents 

Any member 
oflAO 

102 

4:30:00 

406:00:00 

410:30:00 

406.0 

0.2512 

3.98 

lAO Reviews Validation Report 

Any member 
oflAO 

101 

0:00:00 

790:30:00 

790:30:00 

790.5 

0.1278 

7.83 

lAO Updates Artifacts 

Any member 
oflAO 

11 

0:00:00 

94:30:00 

94:30:00 

94.5 

0.1164 

8.59 

lAO Updates lA Control Plan 

Any member 
oflAO 

12 

0:00:00 

99:30:00 

99:30:00 

99.5 

0.1206 

8.29 

MCEN Acknowledges Receipt 

Any member 
of MCEN 
C&A Team 

106 

0:00:00 

111:30:00 

111:30:00 

111.5 

0.9507 

1.05 

MCEN Prioritizes Package 

Any member 
of MCEN 
C&A Team 

106 

0:00:00 

835:00:00 

835:00:00 

835.0 

0.1269 

7.88 

PM Corrects DIP 

PM 

18 

48:00:00 

145:00:00 

193:00:00 

145.0 

0.1241 

8.06 

PM Creates Preliminary Plan 

PM 

119 

172:30:00 

2838:00:00 

3010:30:00 

2838.0 

0.0419 

23.85 

PM Creates Preliminary SIP 

PM 

100 

57:00:00 

2377:00:00 

2434:00:00 

2377.0 

0.0421 

23.77 

PM Determines COA 

PM 

4 

2:00:00 

97:30:00 

99:30:00 

97.5 

0.0410 

24.38 

PM Determines COAl 

PM 

5 

35:00:00 

123:00:00 

158:00:00 

123.0 

0.0407 

24.60 

PM Develops POAM 

PM 

91 

249:30:00 

1446:00:00 

1695:30:00 

1446.0 

0.0629 

15,89 

PM Executes the DIP 

PM 

102 

431:00:00 

800:00:00 

1231:00:00 

800.0 

0.1275 

7.84 

PM Initiates Corrective Action 

PM 

1 

0:00:00 

5:00:00 

5:00:00 

5.0 

0.2000 

5.00 

PM Registers IS in DITPRDON 

PM 

100 

172:00:00 

198:00:00 

370:00:00 

198.0 

0.5051 

1.98 

PM Registers IS with DON lA 

PM 

100 

542:00:00 

198:00:00 

740:00:00 

198.0 

0.5051 

1.98 

PM Reviews Package 

PM 

104 

227:00:00 

815:00:00 

1042:00:00 

815.0 

0.1276 

7.84 

PM Reviews Validation Report 

PM 

101 

378:30:00 

790:30:00 

1169:00:00 

790.5 

0.1278 

7.83 

PM Reviews the SIP and DIP 

PM 

104 

159:30:00 

866:30:00 

1026:00:00 

866.5 

0.1200 

8.33 

PM Submits Package to CAR 

PM 

101 

284:00:00 

199:30:00 

483:30:00 

199.5 

0.5063 

1.98 

Reviewer Acknoledges Receipt 

Any member 
of MCEN 
C&A Team 

107 

0:00:00 

112:30:00 

112:30:00 

112.5 

0.9511 

1.05 

Reviewer Analyzes DIP 

Any member 
of MCEN 
C&A Team 

107 

0:00:00 

4245:00:00 

4245:00:00 

4245.0 

0.0252 

39.67 

Reviewer Documents Comments 

Any member 
of MCEN 
C&A Team 

107 

0:00:00 

6385:00:00 

6385:00:00 

6385.0 

0.0168 

59.67 

Reviewer Submits DIP to CA 

Any member 
of MCEN 
C&A Team 

107 

0:00:00 

213:30:00 

213:30:00 

213.5 

0.5012 

2.00 

Site 

lAM 

20 

7897:30:00 

40:30:00 

7938:00:00 

40.5 

0.4938 

2.03 

System 

lAM 

80 

32846:00:00 

82:30:00 

32928:30:00 

82.5 

0.9697 

1.03 

UR Acknoledges Receipt of SIP 

User Rep 

100 

95:00:00 

104:30:00 

199:30:00 

104.5 

0.9569 

1.05 

UR Develops POAM 

User Rep 

91 

71:00:00 

1446:00:00 

1517:00:00 

1446.0 

0.0629 

15.89 

UR Reviews Package 

User Rep 

110 

326:30:00 

867:30:00 

1194:00:00 

867.5 

0.1268 

7.89 


96 

















































Activity 

Performer 

Occurs 

Waiting 

Time 

fMe) 

Time to 
Complete 
(Time) 

Total Time 
(Time) 

Work 

Time 

(Hours) 

Fired/Hour 

AWT 

UR Reviews Preliminary SIP 

User Rep 

100 

146:00:00 

833:00:00 

979:00:00 

833.0 

0.1200 

8.33 

UR Reviews the SIP and DIP 

User Rep 

107 

45:00:00 

897:30:00 

942:30:00 

897.5 

0.1192 

8.39 

Val Identifies Vulnerabilities 

Any member 
of MCEN 
C&A Team 

114 

0:00:00 

453:00:00 

453:00:00 

453.0 

0.2517 

3.97 

Validator Analyzes Test Results 

Any member 
of MCEN 
C&A Team 

114 

0:00:00 

947:30:00 

947:30:00 

947.5 

0.1203 

8.31 

Validator Assesses Risk 

Any member 
of MCEN 
C&A Team 

99 

0:00:00 

1567:00:00 

1567:00:00 

1567.0 

0.0632 

15.83 

Validator Assigns Severity Codes 

Any member 
of MCEN 
C&A Team 

99 

0:00:00 

784:30:00 

784:30:00 

784.5 

0.1262 

7.92 

Validator Compiles Test Results 

Any member 
of MCEN 
C&A Team 

101 

0:00:00 

790:30:00 

790:30:00 

790.5 

0.1278 

7.83 

Validator Creates Scorecard 

Any member 
of MCEN 
C&A Team 

101 

0:00:00 

396:30:00 

396:30:00 

396.5 

0.2547 

3.93 

Validator Determines Fixes 

Any member 
of MCEN 
C&A Team 

114 

0:00:00 

1816:00:00 

1816:00:00 

1816.0 

0.0628 

15.93 

Validator Determines POAM 

Any member 
of MCEN 
C&A Team 

99 

0:00:00 

393:30:00 

393:30:00 

393.5 

0.2516 

3.97 

Validator Documents Risk Levels 

Any member 
of MCEN 
C&A Team 

99 

0:00:00 

586:30:00 

586:30:00 

586.5 

0.1688 

5.92 

Validator Documents Test Results 

Any member 
of MCEN 
C&A Team 

114 

0:00:00 

1360:00:00 

1360:00:00 

1360.0 

0.0838 

11.93 

Validator Evaluates Impact 

Any member 
of MCEN 
C&A Team 

94 

0:00:00 

742:00:00 

742:00:00 

742.0 

0.1267 

7.89 

Validator Maps Vulnerabilities 

Any member 
of MCEN 
C&A Team 

113 

0:00:00 

2708:00:00 

2708:00:00 

2708.0 

0.0417 

23.96 

Validator Notes Discrepancies 

Any member 
of MCEN 
C&A Team 

114 

0:00:00 

687:30:00 

687:30:00 

687.5 

0.1658 

6.03 

Validator Notifies PM 

Any member 
of MCEN 
C&A Team 

4 

0:00:00 

8:30:00 

8:30:00 

8.5 

0.4706 

2.13 

Validator Performs GAP Analysis 

Any member 
of MCEN 
C&A Team 

114 

0:00:00 

1816:00:00 

1816:00:00 

1816.0 

0.0628 

15.93 

Validator Reviews CA Plan 

Any member 
of MCEN 
C&A Team 

127 

0:00:00 

2023:30:00 

2023:30:00 

2023.5 

0.0628 

15.93 

Validator Reviews Control Plan 

Any member 
of MCEN 
C&A Team 

127 

0:00:00 

1075:30:00 

1075:30:00 

1075.5 

0.1181 

8.47 

Validator Reviews Scorecard 

Any member 
of MCEN 
C&A Team 

101 

0:00:00 

396:30:00 

396:30:00 

396.5 

0.2547 

3.93 

Validator Submits Report 

Any member 
of MCEN 
C&A Team 

101 

0:00:00 

199:30:00 

199:30:00 

199.5 

0.5063 

1.98 

Validator Validates lA Controls 

Any member 
of MCEN 
C&A Team 

114 

0:00:00 

2726:30:00 

2726:30:00 

2726.5 

0.0418 

23.92 



Resource 

Unit 

Cust/Unit 

Threshold 

Usage 



Times 

Fired 

(Sum) 

Times 

Fired 

/Hour 

AWT 

(Hours) 

(Sum) 

CA 

Hour 

0 

0 

1710:30:00 

0 

632 

0.0180 

2.70649 

DAA 

Hour 

0 

0 

4268:30:00 

0 

917 

0.0261 

4.65485 

lAM 

Hour 

28.45 

0 

34485:30:00 

981112.48 

2885 

0.0822 

11.9534 

Any member of lAO 

Hour 

23.74 

0 

26658:00:00 

632860.92 

1990 

0.0567 

13.396 

Any member of MCEN C&A Team 

Hour 

0 

0 

46122:30:00 

0 

4723 

0.1346 

9.76551 

PM 

Hour 

28.45 

0 

10899:00:00 

310076.55 

1050 

0.0299 

10.38 

User Rep 

Hour 

12.95 

0 

4148:30:00 

53723.08 

508 

0.0145 

8.16634 
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Performers queue length and utilization 


1 



Min 

Max 

Utilize^ 

Idlef%) 

CA 

0 

0 

2 

4.87 

95.13 

DAA 

0.03 

0 

3 

12.16 

87.84 

lAM 

34.61 

0 

63 

98.27 

1.73 

Any member of lAO 

0 

0 


18.99 

81.01 

Any member of MCEN C&A Team 

0 

0 

0 

0.66 

99.34 

PM 

0.08 

0 

5 

31.06 

68.94 

User Rep 

0.02 

0 

3 

11.82 

88.18 

Bottlenecks 


Process 

Activitj 

Performer 

Avg ^Meue 
Length 

Min Oiipiip 
Length 

Ms Queue 
Length 

TSOKC_DIACAP_ToBe_VB_rinal 

CA 

Acknoledges 
Receipt of SIP 

CA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

CA 

Acknowledges 

Validation 

CA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

CA Files 
Preliminary 

SIP 

CA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

CA Forwards 
Package 

CA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

CA Reviews 

SIP and DIP 

CA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

CA Submits 
DIP to DAA 

CA 

0 

0 

2 

TSOKC_DIACAP_ToBe_VB_rinal 

DAA 

Acbioledges 
Receipt of DIP 

DAA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

DAA 

Acknoledges 
Receipt of SIP 

DAA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

DAA Files 
Preliminary 

SIP 

DAA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

DAA Grants 
Accreditation 

DAA 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VB_rinal 

DAA Notifies 
PM 

DAA 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VB_rinal 

DAA Returns 
Approved DIP 
to PM 

DAA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

DAA Reviews 
CA Comments 

DAA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

DAA Reviews 
Package 

DAA 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VB_rinal 

DAA Reviews 
Preliminary 

SIP 

DAA 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM Compiles 
CA Package 

lAM 

1.23 

0 

6 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM Compiles 
SIP and DIP 

1AM 

1.36 

0 

5 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM Confirms 
System is lAW 
DIP 

lAM 

1.23 

0 

5 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM Corrects 
DIP 

lAM 

0.22 

0 

2 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM Creates 
Preliminary 
Plan 

lAM 

1.39 

0 

5 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM Creates 
Preliminary 

SIP 

lAM 

1.13 

0 

4 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM 

Determines 

COA 

lAM 

0.04 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM 

Determines 

COAl 

lAM 

0.05 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM 

Determines 

Inheritance 

lAM 

1.48 

0 

4 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM 

Determines 
MAC and CL 

lAM 

1.47 

0 

5 
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Process 

Activity 

Performer 

Avg Qiipnt> 
Length 

Min Queue 
Length 

Mua Queue 
Length 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM Develops 
POAM 

lAM 

1.06 

0 

5 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Develops 
Requirements 

lAM 

1.36 

0 

5 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM Finalizes 
lA Controls 

lAM 

1.48 

0 

4 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM Fixes 
Problems in 
Plan 

lAM 

0.16 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Identifies 
NonApplicable 

lAM 

1.47 

0 

4 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Identifies 
the IS 

lAM 

1.18 

0 

4 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Initiates 
DIP 

lAM 

1.45 

0 

5 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM Lists 
Requirements 

lAM 

0.38 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Monitors 
lA Control 

lAM 

1.41 

0 

6 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Performs 
Final Review 

lAM 

1.25 

0 

6 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Reviews 
Discrepancies 

lAM 

0.14 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Reviews 
lA Baseline 
Controls 

lAM 

1.84 

0 

5 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Reviews 
lA Control 

Plan 

lAM 

1.27 

0 

5 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Reviews 
Validation 
Report 

lAM 

1.2 

0 

5 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Reviews 
the DIP 

1AM 

1.66 

0 

5 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Submits 
Package 

lAM 

1.22 

0 

6 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Submits 
Package1 

lAM 

1.24 

0 

5 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Submits 
Preliminary 

SIP 

lAM 

1.17 

0 

4 

TSOKC_DIACAP_ToBe_VB_rinal 

1AM Submits 
SIP and DIP to 
CAR 

lAM 

1.51 

0 

6 

TSOKC_DIACAP_ToBe_VB_rinal 

lAM Tests lA 
Control 

lAM 

1.4 

0 

6 

TSOKC_DIACAP_ToBe_VB_rinal 

lAO 

Assembles 

DIP 

Components 

Any 

member of 
lAO 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

lAO Builds lA 
Controls into 

IS 

Any 

member of 
lAO 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

lAO Reviews 
Documents 

Any 

member of 
lAO 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

PM Corrects 
DIP 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

PM Creates 
Preliminary 
Plan 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

PM Creates 
Preliminary 

SIP 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

PM 

Determines 

COA 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

PM 

Determines 

COAl 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

PM Develops 
POAM 

PM 

0.01 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

PM Executes 
the DIP 

PM 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VB_rinal 

PM Registers 

IS in 

DITPRDON 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

PM Registers 

IS with DON 
lA 

PM 

0.02 

0 

1 
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Process 

Activity 

Performer 

Avg Queue 
Length 

Min Queue 
Length 

Ma^ Queue 
Length 

TSOKC_DIACAP_ToBe_VB_rinal 

PM Reviews 
Package 

PM 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VB_rinal 

PM Reviews 
Validation 
Report 

PM 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VB_rinal 

PM Reviews 
the SIP and 

DIP 

PM 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

PM Submits 
Package to 
CAR 

PM 

0.01 

0 

2 

TSOKC_DIACAP_ToBe_VB_rinal 

Site 

lAM 

0.23 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

System 

lAM 

0.94 

0 

3 

TSOKC_DIACAP_ToBe_VB_rinal 

UR 

Acbioledges 
Receipt of SIP 

User Rep 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

UR Develops 
POAM 

User Rep 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

UR Reviews 
Package 

User Rep 

0.01 

0 

3 

TSOKC_DIACAP_ToBe_VB_rinal 

UR Reviews 
Preliminary 

SIP 

User Rep 

0 

0 

1 

TSOKC_DIACAP_ToBe_VB_rinal 

UR Reviews 
the SIP and 

DIP 

User Rep 

0 

0 

1 

Note: 

Red-marked Waiting Time values indicates "Activity has waiting time" 

Red-marked Usage values indicates "Usage crossed threshold" 
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